Új hozzászólás Aktív témák
-
Krystal_s
addikt
Most akkor hogy is van ez?
Microsoft does it again, botches KB 2992611 SChannel patch -
#40553216
törölt tag
Javítandó a cikkben írtakat, a CVE-2014-6321 (Schanel) súlyossági értéke nem 9,3, hanem 10.
-
válasz
#82729984
#149
üzenetére
Szerintem felfogni sem tudja milyen az amikor egy cégnek több ezer szervere van és több tizezer alkalmazotta, akik windowst használnak és policyból kötelező az explorer más nem is lehet a gépen.
Én elég nagy vállalatnál dolgoztam (20e+ alkalmazott), de elég gyenge az a policy, ahol nem tudnak meghozni önvédelemből egy olyan döntést, hogy IE stop. És még gyengébb a szervezettség, ha nem tudják ezt akár 1-2 nap alatt mással helyettesíteni. Nálunk apaból két böngésző volt a gépeken, az IE melett egy másik, és pontosan azért, hogy hogy bármelyik leállítható legyen.És akkor ő fogná és lelőné a webszervereket amik mondjuk 30 országban vannak szétszórva (tehát már csak technikailag sem egyszerü a helyzet) és amiknek a leállása mondjuk óránként 1-2 millió dolláros kárt okoznának a cégnek (pl. egy nemzetközi banknál hirtelen megszünne teljes online bankolás), meg kitiltaná az explorert ezzel kb. összeomlasztva a cég müködését és a károk mindjárt egy-két nagyságrenddel nőnének.
Webszerver alatt sok szolgáltatás érthetünk. Egy ilyen téren veszélyeknek kitett vállalatnak mindig van policy-je, hogy egy adott veszélyt milyen szintűnek ítélnek meg, és arra milyen szintű lépéseket tesznek meg. Hidd el, van olyan veszély, ahol lehet ez a döntés. Ha ez nem szerepel a policy-ban, nincs normálisan megszervezve a vállalat.Ja és természetesen mindezt úgy tenné hogy kutyát nem kérdezné meg hogy mindez mit fog okozni mert szerinte a buisness meg az it az két teljesen különböző dolog, és ő it-ésként úgy állítgathatja a rendszert ahogy neki tetszik abba még a vezérigazgató sem pofázhat bele...
Nem is kell megkérdeznie. Ezeket előtte kell definiálni, utána már csak a veszélyt kell besorolni valahová. A policy megmondja azt is, kiket, milyen módon kell értesíteni. A vezérigazgató ebbe nem szokott beleszólni. Nem az ő területe. Ha beleszól, akkor is már maximum azután, hogy végigfutottak az eljáráson. -
stopperos
senior tag
Eközben a hup-on: Vírusirtó vs. 0day bug
-
sh4d0w
félisten
válasz
#79563158
#147
üzenetére
Valóban, de a DRP-nek része kell, hogy legyen, ha súlyos, a céget is érintő sebezhetőség bukkan fel az Interneten. Amíg a döntéshozók összeülnek és döntésre jutnak olyan témában, amihez nem értenek, addigra a cég hálózata egy botnet része lehet, ami nyilvánvalóan nem engedhető meg. A shellshock is megmutatta, hogy semmi idő alatt össze lehet rakni egy botnetet.
-
#82729984
törölt tag
válasz
#79563158
#145
üzenetére
bambanovel teljesen feleslegesen vitatkozol (egyébként neked van igazad).
Alapvetően egy garázs bt rendszergazdájával beszélgetsz, akinek olyan workaroundjai vannak ilyen hibára hogy leállítja az összes webszervert (muhaha) meg hogy kitiltja az internet explorert és hogy leginkább az ő cégénél nem is használnak windowst meg különben is...
Szerintem felfogni sem tudja milyen az amikor egy cégnek több ezer szervere van és több tizezer alkalmazotta, akik windowst használnak és policyból kötelező az explorer más nem is lehet a gépen.
És akkor ő fogná és lelőné a webszervereket amik mondjuk 30 országban vannak szétszórva (tehát már csak technikailag sem egyszerü a helyzet) és amiknek a leállása mondjuk óránként 1-2 millió dolláros kárt okoznának a cégnek (pl. egy nemzetközi banknál hirtelen megszünne teljes online bankolás), meg kitiltaná az explorert ezzel kb. összeomlasztva a cég müködését és a károk mindjárt egy-két nagyságrenddel nőnének.
Ja és természetesen mindezt úgy tenné hogy kutyát nem kérdezné meg hogy mindez mit fog okozni mert szerinte a buisness meg az it az két teljesen különböző dolog, és ő it-ésként úgy állítgathatja a rendszert ahogy neki tetszik abba még a vezérigazgató sem pofázhat bele...
Előzetes tesztelésről már nem is beszélve, mert bár erről nem beszélt de gondolom aki ilyen profi a workaround területén, az nem fog holmi teszteléssel vesződni, hanem rögtön az éles mission critical production szerveren fogja elvégezni a változtatásokat... -
bambano
titán
válasz
#79563158
#145
üzenetére
én nem tehetek arról, hogy vagy nem olvastátok el a hozzászólásaimat, vagy nem értettétek meg.
"a szerinted az üzleti oldalnak semmi köze nincs az IT-hoz, akkor részemről felesleges miről beszélnünk": én sehol nem mondtam ilyet.
"Komplett folyamatokat alakítanál át és szoftvereket blokkolnál azért, hogy egy kockázatot csillapíts": ilyet se mondtam.
"ezek után is kitartasz amellett, hogy publikálniuk kellett volna patch nélkül a sérülékenységet.": igen, ezek után is kitartok amellett, hogy mivel a rossz emberek valószínűleg hozzájutottak a sérülékenységhez, ezért mindenkinek tudnia kellett volna. ez pont olyan, mint amikor felrobbant csernobil, neked nem szóltak időben, így a napi tevékenységed alakításában nem vetted figyelembe, bekaptál egy rákot. (általános alany, mielőtt a funkcionális analfabéták belekötnének).
"Ezek mellett DRP-re hivatkozol ott ahol kijött egy új sérülékenység, de nem történt incidens.": a drp-re akkor kezdtem el hivatkozni, amikor az eredeti problémáról elterelődött a téma.
"A PoC-al kapcsolatos elemzésed újabb ékes bizonyítéka annak, hogy nem értesz hozzá, de váltig állítod, hogy lehet blokkolni a polimorfikus kódot.": neked meg a magyar nyelvhez nincs közöd, ha a feltételes módot nem tudod értelmezni. -
#79563158
törölt tag
bambano: Felhoztam/hoztunk egy rakás szakmai érvet, de ha szerinted az üzleti oldalnak semmi köze nincs az IT-hoz, akkor részemről felesleges miről beszélnünk. Komplett folyamatokat alakítanál át és szoftvereket blokkolnál azért, hogy egy kockázatot csillapíts, de ezek után is kitartasz amellett, hogy publikálniuk kellett volna patch nélkül a sérülékenységet. Ezek mellett DRP-re hivatkozol ott ahol kijött egy új sérülékenység, de nem történt incidens. Nálatok akkor minden sérülékenység megjelenésekor életbe lép a DRP? A PoC-al kapcsolatos elemzésed újabb ékes bizonyítéka annak, hogy nem értesz hozzá, de váltig állítod, hogy lehet blokkolni a polimorfikus kódot.
-
bambano
titán
az, hogy havária esetén nem döntögetünk, hanem cselekszünk, vállalat méretétől független.
maximum az változik, hogy ki mit kérhet utána számon.
ha olyan nagy a cég, hogy nem lehet megélni szleng nélkül, és biznisznek kell nevezni az egyik osztályt (és tegyük fel, hogy nem teljesen hanyagok/idióták), akkor ott van drp (magyarul katasztrófa elhárítási terv).azt kell végrehajtani.
rendes helyen vagy nagyon ért valaki a drp-hez, vagy külső szakértő bagázs megcsinálja egy kalap pénzért, utána szintén rendes helyen begyakoroltatják. ha beüt a krach, álmából felébresztik a kómás rendszergazdát, akkor is végre kell tudni hajtani, meg kell tudni védeni az értékes adatokat.
ellenkező esetben jön az a történet, hogy index címlapos lesz a "Kikerült egy csomó ügyfél adata x.y cégtől", meg mindenféle hatóság próbál majd okoskodni vizsgálat címszó alatt, és akkor hónapokig zajlik majd a kármentés, meg a mosakodás. ha meg belecsaptál a lecsóba és megoldottad a problémát, akkor csak arról fog szólni a történet, hogy pár ügyfél nem tudta megoldani, amit szeretett volna, a szolgáltatásra vonatkozó éves rendelkezésre állás lement 0.05 százalékkal.
-
fsb1000
nagyúr
Nem lehet hogy te olyan vállalati szféráról beszélsz, ahol a tulajdonosi kör élesen elválik a vezetőitől?
A veled egyet nem értők, meg lehet középvállatoknál szerzet tapasztalatikra alapozva gondolják úgy, hogy a cégvezetés szinte minden döntési jogkört sajátjának tekint, mert részben vagy egészben tulajdonos is?
.
Az "alkalmazotti" státuszban lévő felső vezetők habitusa eltérést szokott mutatni azokétól akik tulajdonosként vállalnak vezetői szerepet. -
bambano
titán
válasz
velizare
#139
üzenetére
ugye tisztán érzed te is, hogy ezt a sok marhaságot már csak azért erőlteted, hogy a tied legyen az utolsó szó? mert szakmai érv, pláne cáfolatlan szakmai érv nem hangzott el tőletek már jó ideje.
erőltettétek, hogy döntsön az ms, mert ezmegaz, kiderült, hogy az érvelés ökörség volt.
most erőlteted ezt a bizniszt, ez is ökörség, de teszek még egy kísérletet:
amikor beüt a szar, akkor a biznisznek nincs döntési jogköre, továbbmegyek: fizikailag nincs döntési lehetősége sem (mert amikor fontos adatok kerülnek veszélybe, akkor nem arra fogunk várni, hogy a biznisz összeüljön és megtárgyalják a helyzetet, majd hozzanak egy döntést, ami szakmailag nem megalapozott, mert nem az ő szakmájuk). döntési jogköre akkor volt (ha már akkora nagy cégben gondolkodunk, hogy külön társaság van, akiket muszáj biznisznek hívni és nem lehet normális magyar nevén nevezni, tehát egy ekkora cégben) döntési jogköre, mikor a drp-t elfogadták.én végrehajtom a drp-t, ha ez ellen a biznisz pattog, ugyanúgy pofára fog esni, mint most ti. és ha rendesen megcsinálták a drp-t (én meg szoktam), akkor abban az is le van írva, hogy a biznisznek mi a dolga ilyen esetekben. tehát nemhogy az informatikai részben nem kapnak döntési jogkört, a saját területükön sincs döntési jogkörük, mert azt nem várja el senki, hogy pánikhangulatban elsőre jól döntsenek. Ehelyett van a drp, azt kell NEKIK IS végrehajtani.
ennyi a történet. fogadd el, hogy tapasztalatból beszélek.
-
-
bambano
titán
válasz
#79563158
#137
üzenetére
olyan nincs, hogy felvetődik a lehetősége, hogy szétvágják a teljes informatikádat, és akkor az nem zavar senkit. itt max. azon agyalhatsz, hogy melyik verzió zavar kisebbet és/vagy melyik zavar rövid/hosszú távon kisebbet.
"A PDF-re konvertálás pont annyira megfelelő, mintha a PSD, az AI és az INDD fájlokat PNG-be konvertálnád Adobe sérülékenység esetén": a pdf-re konvertálás sokat segít, amikor éppen az ole sebezhetőség a sláger a neten. Amikor megjön az ole sebezhetőség javítása, akkor majd nem konvertálunk tovább pdf-re.
"Amúgy az általad valós opcióként kezelt megoldásokra szerinted kinek van ideje, amikor például az egyik legnagyobb hazai bank leányvállalatánál arra nincs idejük a rendszergazdáknak, hogy felrakjanak egy service packot?": én nem mondtam, hogy nem lehet fejjel menni a falnak... ha havária van, akkor túlóra is.
és ha a legnagyobb hazai bank leányánál service packot sincs idő felrakni, akkor szerinted azt a patchet fel fogják rakni, amit végül fél év után kiadnak? hint: nem. tehát náluk sem okoz semmi különbséget, ha időben kiadják.
-
#79563158
törölt tag
Az általad felvázolt folyamat addig működik, amíg az nem jár extra költségekkel vagy nem zavar senkit. Ha a kettő közül valamelyik teljesül (új szerver / vállalat által használt szoftver blokkolása) ott már minden normális helyen beszélni kell a nem-IT felettessel is, mielőtt valami drasztikusat lépnél.
A PDF-re konvertálás pont annyira megfelelő, mintha a PSD, az AI és az INDD fájlokat PNG-be konvertálnád Adobe sérülékenység esetén. Amúgy az általad valós opcióként kezelt megoldásokra szerinted kinek van ideje, amikor például az egyik legnagyobb hazai bank leányvállalatánál arra nincs idejük a rendszergazdáknak, hogy felrakjanak egy service packot?
-
bambano
titán
válasz
#79563158
#134
üzenetére
Megmondom, egy ilyen esetben ez hogy zajlik:
- megjön a hír a bugról
- felrakom a védekezést, jár, amivel jár
- utólag értesítem a businesst, hogy ez történt.az, hogy a business előzetes konzultációs, pláne beleszólási jogot kapjon egy ilyen szintű hálózatbiztonsági kérdésbe, nonszensz. és nem csak nálam nonszensz, hanem minden nagyobb cégnél is. a biznisznek utólagos értesülési meg egyetértési joga van. max. az adatvédelmi felelősnek van joga beleszólni előzetesen, de csak akkor, ha véletlenül nem én vagyok az is. és ne aggódj, ezt az eljárást teszteltem már nagy multinál is, és bevált.
egyébként ezt a módszert indokolja az is, hogy mire a biznisznek ideje lenne nyikkanni, rég túlvagyunk mindenen. betörési szándékú embereknél rendszerint nem jön be a "pihengessél már egy kicsit, míg a managgák megmítingelik a kérdést és kitalálnak valamit" stílus. hiába magyaráznám egy kínai crackernek, hogy várjá' má, még nem ért véget a
petmíting, ne támaggyá má, csak majd utána."Ettől függetlenül így is álló farokkal az aknamezőre kaliberű ötletnek tartom a sérülékenység patch nélküli publikálást.": ez a mondat már rendben van, mert ebben már magánvéleményt fogalmazol meg.
"végig az OLE sérülékenységekre gondoltam": amely ellen triviális védekezés, ha a határvédelemben az ole alapú dokumentumokat libreoffice-vel pdf-re konvertálják. Az, hogy esetleg egy-két formázás szétcsúszik, nem túl nagy ár azért, hogy nem viszik el a cégből a fontos adatokat.
-
bambano
titán
válasz
Gregorius
#133
üzenetére
ahol én dolgozom, ott pl. egy licenszet sem vesznek. szerinted meg tudjuk oldani vagy sem?
de úgy látom, szőrszálhasogatással próbálod te is menteni a menthetetlent.
"A kicsomagolás-kielemzés-újra összerakás az nem átkódolás": nem, mert az nem egy átkódolt csomag, hanem egy teljesen új csomag, és mint ilyen, nincs benne szabálytalan protokoll üzenet. ráadásul a támadás okát adó protokoll egyáltalán nincs benne.
"Ha az előtét nem egyszerűen továbbítja a csomagokat, annak komoly erőforrásigénye és nem utolsó sorban késleltetése van.": bejön egy titkosított csomag, kimegy egy titkosítatlan. következésképp feltételezni, hogy egyszerű továbbításról van szó, marhaság.
ezen hsz alapján elég nyilvánvalóvá vált számomra, hogy fogalmad sincs, mi az, amin éppen csomót keresel.
"Ha érvényesek, akkor egy ilyen előtét nem sokat ér.": a titkosítást, amit éppen támadni akarnak, lebontja az apacs. rá nem hat semmi, ami egy windows szervert kiborítana, tehát hiába támadod az apacsot windowsos exploittal, felesleges próbálkozás, mint egyszeri kurvánál a széchenyi utalvány.
hogy kinek mi a komoly erőforrásigény meg késleltetés, azt én nem tudom megmondani. előfordulhat, hogy neked vagy átlag windows adminnak az komoly erőforrásigényű. nekem, mint olyan linuxos rendszergazdának, aki *már csinált* ilyet, nem csak beleugat a levegőbe, nem komoly.
-
#79563158
törölt tag
bambano: Nagyon ügyes vagy, de a megoldásod kábé annyira reális mint az, hogy a business rábólint arra, hogy oké, akkor holnaptól hanyagoljuk az IE-t. De tegyük fel, hogy ezt megoldásnak elfogadjuk, most már csak kismillió nem-céges felhasználó lett volna veszélyben a hiba azonnali publikálása miatt.
Gregorius: CVE-6332 Az alatta lévő 6352-vel keverted, ahhoz van workaround.
Amúgy elnézést mindenkitől, ahogy Gregorius rávilágított jól elbeszéltünk egymás mellett. Én -hibásan- végig az OLE sérülékenységekre gondoltam, nem a Schanellre mint amiről a cikk szól. Ettől függetlenül így is álló farokkal az aknamezőre kaliberű ötletnek tartom a sérülékenység patch nélküli publikálást.
-
Gregorius
őstag
kíváncsi vagyok, redmondban hány cégről tudják korrekten eldönteni, hogy fel tud-e húzni egy frontendet vagy sem.
Feltéve hogy nincs komolyabb telemetriájuk az ügyfélkörről (de van) csak annyit kell megnézniük, hogy egy cég átlag hány licenszet vesz és máris van halvány fogalmuk róla, hogy nagyságrendileg hogy állnak a dolgok. Egy ilyen eloszlást kigyűjteni még úgy is könnyű, hogy nem gyűjthetnek olyan információt, ami egyedileg azonosítja az ügyfelet.nincs átkódolt packet, következésképp nincs, ami elbarmolja a szervert. Az apacs alkalmazásszintig kicsomagolja a bejövő kéréseket, kielemzi és újra összerakja nulláról
A kicsomagolás-kielemzés-újra összerakás az nem átkódolás? Most itt nem feltétlenül újratitkosításra gondolok. Ha az előtét nem egyszerűen továbbítja a csomagokat, annak komoly erőforrásigénye és nem utolsó sorban késleltetése van. Azt sem tudjuk továbbá, hogy az érintett csomagok egyébként érvényes (de valószínűtlen) protokollüzenetek-e vagy sem. Ha érvényesek, akkor egy ilyen előtét nem sokat ér. -
bambano
titán
válasz
Gregorius
#131
üzenetére
kíváncsi vagyok, redmondban hány cégről tudják korrekten eldönteni, hogy fel tud-e húzni egy frontendet vagy sem.
"Mert amelyik igen, annál gyanítom, hogy már meg van valósítva az általad vázolt felállás.": ezt a mondatodat kiemelném vastagon...
"Amíg nincs PoC, addig nehéz megmondani, hogy működne-e ez a megoldás vagy az átkódolt packet ugyanúgy elbarmolná a belső szervert.": ezt triviálisan el lehet dönteni: nincs átkódolt packet, következésképp nincs, ami elbarmolja a szervert. Az apacs alkalmazásszintig kicsomagolja a bejövő kéréseket, kielemzi és újra összerakja nulláról. Majd ezt a csomagot úgy küldi el a szervernek, hogy teljesen kihagyja az schannelt, akkor nemigen történik semmi hátrányos. Vagy egy reverse proxy squidból...
"Amúgy meg nem mind http, ami TLS.": biztos találnék más beágyazott protokollra is proxyt, vagy csak egy sima tcp proxyt, ami kicsomagolja a tls-t.
-
Gregorius
őstag
Kíváncsi vagyok, hogy a cégek hány százaléka tud csípőből felhúzni egy extra réteget az érintett szerverek elé (már ha a protokoll miatt ez egyáltalán lehetséges), ráadásul úgy, hogy terhelésügyileg elbírja az átmenő forgalmat (ugye újra kell kódolnia mindent). Mert amelyik igen, annál gyanítom, hogy már meg van valósítva az általad vázolt felállás.
Amíg nincs PoC, addig nehéz megmondani, hogy működne-e ez a megoldás vagy az átkódolt packet ugyanúgy elbarmolná a belső szervert.
Amúgy meg nem mind http, ami TLS.
-
bambano
titán
válasz
Gregorius
#129
üzenetére
/nem neked szól, csak a te hsz-edre válaszolok/
óóó, tényleg, ez akkora bug, hogy fél évig kellett kotlani rajta és nyitva hagyni az ajtókat???
mert hátugye alapvetően lehetetlen elképzelés az, hogy felhúzunk egy apacs load balancert a wines szerver elé, amelyik kicsomagolja a https-t, átrakjuk rá a wines szerverről a kulcsokat, hogy ne derüljön ki, hogy másik gépről megy a cucc, és az apacs meg sima http-n lehúzza a windowsos szerverről a tartalmat.
és a microsoft nem volt képes azonosítani egyetlen workaroundot sem? más hozzászólásban azt állították, hogy az ms szerint nincs workaround, az ms weboldalán már az van, hogy nem azonosítottak...
az ms saját háza táján nem tudta megoldani, ezt elhiszem, mert bármit akasztok elé ms cuccból, az ugyanúgy lyukas lesz. na de egy zorp, egy cisco tűzfal, egy debian apaccsal, egy squid reverse proxy, az nem lyukas ezt a bugot tekintve, mivel nincs rajta ms schannel.
tényleg egy ennyire egyszerű megoldás miatt nem publikálták a hibát? ezek után azt sem tudom kizárni, hogy ez perképes és a bíróság elkaszálná az ms-t, ha valakinek eszébe jutna perelni...
-
Gregorius
őstag
@bambano
Arra semmi bizonyíték sincs, hogy a támadó oldal nem tudta meg sokkal hamarabb.
A támadó oldal az nem egy darab entitásból áll. Mindegyiknek megvan a saját privát exploit-listája, amit használ, esetleg kereskedik vele, de ez nagyon távol van attól, hogy mindenki ismer minden hibát. Minél kevesebben tudnak róla, annál kisebb a valószínűsége, hogy felfedezik és javítják.
Sokkal valószínűbb az, hogy igen kevesen tudnak egy hibáról (ha egyáltalán). Viszont ha jön egy disclosure - akár egy olyan ártatlan, ami megnevezi a hibás komponenst - akkor az egész alvilág célirányosan ráuszítja a fuzzert és hirtelen nagyságrenddel megnő a hibát ismerők és kihasználók száma.
Ez utóbbi persze óhatatlanul bekövetkezik, amikor megérkezik a patch, ugyanis egy egyszerű diffből kiderül, hogy hol volt a hiba. (Feltéve, hogy nem használnak valamilyen nondeterminisztikus obfuszkálást, de ez nem jellemző.)@dabadab
Egyebkent a MS azt irja, hogy a problema alapvetoen az IE-t erinti, az azt hasznalok kerulhetnek / kerulhettek bajba
Ezt hol írta?@bambano
megnéztem a trendmicro saját analízisét
Ez nem az a bug. Amit linkeltél az a MS14-064. A cikkben az MS14-066-ról van szó. -
bambano
titán
próbálom értelmezni a poc-ot, úgy tűnik, hogy van benne három konstans, ami esélyes, hogy fix is lehet:
ab(b0)=1.69759663316747E-313 // this is 0×0000000800000008
ab(2)=1.69759663316747E-313
ab(0)=6.36598737437801E-314
ab(2)=1.74088534731324E-310ez alapján akár polimorfikus verziót is meg lehet fogni.
ez persze csak felületes vélemény, de arra alkalmas, hogy az itt elhangzott vélelmeket megdöntse. -
bambano
titán
egyébként meg milyen szép ilyeneket olvasni:
"A stable exploit exists and works in versions of Internet Explorer from 3 to 11, and can bypass operating system (OS) security utilities and protection such as Enhanced Mitigation Experience Toolkit (EMET), Data Execution Prevention (DEP), Address Space Layout Randomization (ASLR),and Control-Flow Integrity (CFI)." -
bambano
titán
válasz
#79563158
#120
üzenetére
itt ment a mantra, hogy nincs ellene védekezés. a cve szerint ez egy vbscript bug. szerinted nekem mennyi idő lenne egy határvédelmi eszközön megoldani, hogy minden bejövő forgalomból gyalulja ki a vbscriptet? összeraknék egy whitelistet, ahonnan bejöhet vbscriptet tartalmazó forgalom, a többiből vagy kiszedem vagy megtiltom oszt jónapot. mivel ezt a határvédelmi eszközön csinálnám, a házon belüli gányolást nem érinti. A cve szerint fertőzött webszerverekről jöhet a kód, oldják meg a rendszergazdák, hogy a saját webszerveren ne legyen ilyen.
egyáltalán nem lehetetlen küldetés. de ti csak mantrázzátok tovább, hogy az ms-nek kell döntenie helyettetek mindenben, engem mostantól nem zavar.
szerk: most kicsit eltekintettem attól az egyébként nem elhanyagolható ténytől, hogy a trendmicro-sok is megoldották ugyanezt a problémát. tehát ha a védelemmel foglalkozó cégeket értesítették volna fél évvel ezelőtt, akkor már fél éve lett volna workaround a bugra. így meg fél évig tárva-nyitva volt minden.
-
It impacts almost all Microsoft Windows versions from Windows 95 onward.
Proof of concept (PoC) exploit code has recently been published by a Chinese researcher named Yuange1975.
Based on the PoC, it’s fairly simple to write malicious VBScript code for attacks.nekem ennyi pont elég arra, hogy amíg nincs rá fix, miért ne büntessünk meg ezzel mindenkit, akit egy script kiddie is be tud támadni. hogy az nsa, meg a többi kémszervezet tudott róla, és használta, különösebben nem mozgat. nem kell naívnak lenni, elég jó valószínűséggel tudnak ők még többről is, platformtól függetlenül, ahogy azt is el tudom képzelni, hogy ez már kikopott az aktívan használt eszköztárukból.
-
bambano
titán
válasz
#79563158
#117
üzenetére
megnéztem a trendmicro saját analízisét, ez nagyjából mindent cáfol, amivel eddig védtétek ezt a tarthatatlan álláspontot.
szerintem most már te is nézd meg az ms sec.buletint, meg azt is, hogy miket hoz a gugli erre a kérdésre.
-
válasz
#79563158
#117
üzenetére
"Azt meg nem is értem, hogy miért gondolod, hogy ilyen esetben nem létezhet polymorphic shellcode."
Azert mert teljesen biztos dolog, hogy a lenyegi resznek fixnek kell lennie - ahogy pl. a Shellshocknal is ez volt a helyzet (pedig ott joval bonyolultabb volt a helyzet) vagy modjuk a Code Rednel.
-
#79563158
törölt tag
Nézd meg a Microsoft Security Bulletint, a tűzfalon nem tudsz semmit sem mókolni, amivel a támadást akadályozni tudod.
dabadab: Mivel memóriakezelési hibát ír az MS, ezért valószínűleg overflow hiba lesz. Azt meg nem is értem, hogy miért gondolod, hogy ilyen esetben nem létezhet polymorphic shellcode.
A lényeg, hogy mivel a CVE-2014-6332-re (a gyártó szerint) nincs workaround, ezért semmit nem nyertek volna ha azonnal publikus lett volna a hiba, ellenben boldog-boldogtalan próbálkozhatott volna a hiba kihasználásával legalább pár napig/hétig és a publikus exploit után a script kiddiek biztosan ezzel szórták volna a népet.
-
válasz
#79563158
#112
üzenetére
Egyreszt ahogy elneztem, meg nincs hozza PoC, tehat eleve valoszinutlen, hogy itt a forumon barki tudna, hogy konkretan mirol van szo, masreszt ami eddig kiderult, az alapjan inkabb valami buffer overflow vagy hasonlo hiba lehet, ahol elso korben a polimorfizmus nem szamit, mert valami kellokeppen elrontott packet kell hozza.
Egyebkent a MS azt irja, hogy a problema alapvetoen az IE-t erinti, az azt hasznalok kerulhetnek / kerulhettek bajba - erre meg viszonylag egyszeru workaround, hogy amig nincs javitas, addig nem engedik ki az IE-t az internetre.
-
bambano
titán
válasz
#79563158
#110
üzenetére
"nem tudtál volna megfelelően védekezni ellene sehogy sem.": nem zárom ki ezt a verziót sem, de akkor legalább tudom, hogy a saját döntésemért rúgják szét a seggem, nem valami távoli idegen hülyesége miatt.
A tűzfalon nem a kimenő forgalmat kell ellenőrizni, hanem a bejövő dolgokat, amelyek rejthetik a törésre alkalmas kódot. A shellshockot például lehetett detektálni.
Azért a kimenő forgalommal is van mit kezdeni, ha redditen keresztül beszélget a botnet, akkor tokkal-vonóval letiltom a redditet. Ha tudom, hogy le kell tiltani.
De kanyarodjunk vissza az elejéhez: ha elszabadul valami, azért az én hátsómat rúgják szét. Akkor pedig magamnak akarom a jogot, hogy erről tudjak és dönthessek.
Hagy emlegessek még egy, korábban elhangzott érvet is: itt csak arra van bizonyíték, hogy a védekező oldal nem tudott a bugról. Arra semmi bizonyíték sincs, hogy a támadó oldal nem tudta meg sokkal hamarabb. Az elmúlt időszak eseményei alapján nem alaptalan azt feltételezni, hogy az nsa legalább egy fél éve tudott a bugról és hogy ki is használta. Következésképp az az előny, amit itt az azonnali nyilvánosságra hozás ellen szólna, NEM LÉTEZIK, hamis, fals.
-
#79563158
törölt tag
Jelenleg a polimorfikus kódok miatt a szignatúra alapú azonosítás ki van lőve. A kimenő forgalmat sem tudod igazából azonosítani, mert ugye azt is lehet encryptelni, tunnelezni vagy ahogy az utóbbi OSX botnet megmutatta, akár reddit kommenteken keresztül is lehet üzenni, csak kreativitás és kitartás kérdése. Szóval röviden: nem tudtál volna megfelelően védekezni ellene sehogy sem.
-
bambano
titán
válasz
#79563158
#107
üzenetére
szerintem ha pontosan tudod, hogy milyen bugot fognak támadni, akkor az adott bug ellen lehet védekezni. minden kicselezhető, de a kicselezésre akkor van nagyobb esély, ha nem tudják, hogy mit kell keresni a forgalomban.
a másik lehetőség, hogy elvileg nem egy védelmi vonalad van, így nem feltétlenül egy cégtől jöhet valamilyen megoldás, konkrétan a víruskergetőkre célzok. Ha az ms egy fél év alatt tudta csak befoltozni a lyukat, vagy más hibák esetén is kotlik rajta sokáig, azt a kódot, patternt, ami a lyuk kihasználására van, a víruskergetők hamar belerakhatják az adatbázisukba, és az már ad egy bizonyos védelmet.
illetve ha tudod, hogy hiba van a rendszerben és nem tudsz rá közvetlen orvosságot, akkor még mindig lehetőséged van drasztikus megoldásokról dönteni. nem egy olyan cég/ember dönt helyetted, akinek semmi felelőssége a dologban, hanem az, akinek a hátán csattan az ostor. az ms eula szerint nagyjából semmi felelősséget nem vállalnak, kártérítést sem adnak, ha neked károd származik a programjuk használatából, így minden ilyen felelősség az adott cég illetékesén van. Akkor legyen már meg a jogköre is arra, amit csinál.
(#106) camillus: nem 19 év, csak fél. a legjobb titok az, amit senki sem tud
-
stopperos
senior tag
válasz
camillus
#106
üzenetére
Az apache2 a www-data felhasználóval futott. Illetve a /var/www könyvtárat volt jogosultsága írni. Ez az alap a debian 4-ben, mellesleg hogy tele volt hibával az az apache verzió.
A rendszergazdának általában nincs ideje minden egyes gépet figyelnie, persze ott van van a sok monitoring eszköz, de azok sem mindenre jók. Ez is abból derült ki hogy furcsa forgalom jelent meg, és akkor megindult a keresés.ysengrin: Csak folytatva a gondolatod, ha abból indulsz ki hogy minden törhető és nem bízol meg a gyártó által mondott dolgokban, hanem saját magad is biztosítod. Akkor jársz a legjobban. Mint rendszergazda, ez az eset óta nem bízom meg a mások által telepített majd átvett dolgokban.
-
camillus
tag
válasz
#79563158
#92
üzenetére
És mit csináltál volna addig amig nyilvános
NAT, log file-ok és a perifériák korlátozása, esetleg wireshark. 19 év titoktartás azé' elég durva.
![;]](//cdn.rios.hu/dl/s/v1.gif)
stopperos Nálunk felnyomták még a rédig debian 4-es web szervert 2011-ben, és csak annyi történt, hogy felkerült egy b nevű program, és az folyamatosan törni próbálta a gépeket.
Vagy a felhasználói jogosultságokkal volt valami, és/vagy nem volt elég gyakran futtatva a ps (ha tudták hogy mi nem való oda, ha nem, akkor top).
bambano egyetlen gép sincs, amiért felelősséggel tartozom, és windows van rajta.
"Mázli", de nem mindig lehet ilyen szituban az ember.
-
#101
King Unique
titán
King Unique
titán
Amúgy még az jutott eszembe, h minket leginkább érintő home verziók, mint a Vista/7/8/8.1 megkapták az ok, de vajon a Win10 TP is
Nemrég kijött a 9879-es build, illetve ahhoz volt egy novemberi KB3016725 update, abban már eleve javítva van? Biztos... -
#100
bambano
titán
King Unique
#99
bambano
titán
válasz
King Unique
#99
üzenetére
nem most.
-
#99
King Unique
titán
King Unique
titán
Biztonsági frissítés Windows 8.1 for x64-based Systems rendszerhez KB2992611
Na, felkerült ez is pár napja.
Látom megint megy itt is az elmélkedés, megjelent a sok fanatikus MS hater, fossák a szót és most örülnek, h nem csak a másik OS-t csesztek átnézni rendesen...
(#49) Lapajbacsi: ez alapján minek WU, fel egy jó kis AV, FW, aztán védett lesz akár az XP is az örökkévalóságig...csak sajna nem így van...
-
bambano
titán
válasz
#82729984
#96
üzenetére
vegyünk még be a buliba egy másik szempontot is:
minek az esélye nagyobb: hogy az én gyakorlatilag értéktelen webszerveremet fogják megtámadni, ahonnan megtudhatják, hogy x.y ap-n éppen 3 megabit forgalom van, vagy a világbank szervereit, ennél kicsit fontosabb, értékesebb adatokkal?fentiek tekintetében hogy értékeled, hogy a világbank illetékesei nem tudják, hogy veszélyben vannak???
szerk: és mit fog mondani a cég biztonsági felelőse, mikor megtudja, hogy a háta mögött döntöttek?
egyébként pedig mondtam már, hogy az, hogy a windowson nincs workaround, az mvp?
-
#82729984
törölt tag
"egyetlen gép sincs, amiért felelősséggel tartozom, és windows van rajta."
"a debianos szervereknél meg lenyomtam a webszervereket"Igen, értjük hogy egy garázs bt-nél a mindenes rendszergazdával ez igy müködik, de majd állítsd már le a webszervereket mondjuk egy banknál légyszives amig te fórumokat olvasgatsz hogy van-e valami workaround.
És most ne olyan apró cseprő bankra gondolj mint az OTP, hanem mint mondjuk a World Bank, aminek van néhány tizezer szervere néhány száz országban. És bizony van köztük windows is.Na már most amennyire én tudom a microsoft szerint a hibára nincs workaround, innentől kezdve nagyon is jól tette hogy a javításig nem publikálta a hibát.
Mert a microsoftnak azért van jópár olyan ügyfele ahol a garázs bt-és rendszergazda nem fogja lenyomni a webszervert, meg nem is úgy müködnek a folyamatok hogy a 100. rangú helyi rendszergazda majd éles szerveren próbálgatja az xy fórumokon irtakat néhány óra fórumozás után. -
#94
Lortech
addikt
Lapajbacsi
#49
Lortech
addikt
válasz
Lapajbacsi
#49
üzenetére
Biztonsággal kapcsolatos témákban nem lehetne szakmai alapon moderálni? Legalább a tömény dezinformációt.
emvy: valóban, elnézést, elragadtattam magam.
-
bambano
titán
válasz
#79563158
#92
üzenetére
egyetlen gép sincs, amiért felelősséggel tartozom, és windows van rajta.
továbbmegyek: egyetlen windowsos gép sincs a közelemben.
nem érdekelnek az office dokumentumok, az ie6 meg pláne.mvp. MásValaki Problémája.
a debianos szervereknél meg lenyomtam a webszervereket, megnéztem, hogy van-e mod-cgi, stb. stb. shellshock ellen bizonyos fokig segített a fail2ban. meg tudtam oldani, hogy azok a szolgáltatások, amik fontosak és én felelek értük, biztonsággal üzemelhessenek. ennyi. sokkal jobb céges weblap nélkül üzemelni, mint összedőlni.
szerk: és mivel a shellshock bili elég hamar borult ki, így minden rendszergazda meg tudta hozni a saját döntését. és itt ezen van a hangsúly: lehetőséget kapott a felelőssége mellé.
-
#79563158
törölt tag
És mit csináltál volna addig amig nyilvános de nem javitható? Tiltottad volna az Office dokumentumokat és az Internet Explorert minden felhasználó számára, amig ki nem adják a patchet? Ebben az esetben szerintem a titokban tartás ésszerübb lépés volt, mint a nyilvánosságra hozás.
-
Heartbleed disclosure timeline: who knew what and when
Friday, March 21 or before - Neel Mehta of Google Security discovers Heartbleed vulnerability.
Monday, April 7 10:27 - OpenSSL publishes a Heatbleed security advisory on its website (website metadata shows time as 10:27 PDT).
-
bambano
titán
válasz
#79563158
#84
üzenetére
igen, egyértelműen jó dolog.
egyrészt legyél benne 102%-ig biztos, hogy az nsa tudott a sérülékenységről rögtön azután, hogy felfedezték. másrészt nem lehetsz biztos benne, hogy senki más nem tudott róla. ha találgatnom kellene, azt találgatnám, hogy akik üzemszerűen foglalkoznak törögetéssel, azok is tudtak róla.viszont azok, akik védelemmel foglalkoznak, meg nem.
tehát nem hiszem, hogy a titokban tartás csökkentette a betörések számát, de egyértelmű, hogy a védekezési lehetőséget igen.
a heartbleednél puff kiborult a bili, kapásból lenyomtam az összes webszerveremet, így betörni már nem tudtak. Utána nyugisan elolvastam, hogy mit írnak róla, van-e workaround, stb. és eldönthettem, hogy mit csinálok. a logok szerint csak néhány próbálkozás volt, abból is a többség ilyen "tanulmánynak adatot gyűjtünk" típus.
-
#81
bambano
titán
Döglött Róka
#73
bambano
titán
válasz
Döglött Róka
#73
üzenetére
jaja, az, hogy az opensource azonnal nyilvánosságra hozták a hibákat, valóban ésszerűbb, mint hogy az ms kotlott rajta fél évig. mert ezzel, hogy az ms nem hozta nyilvánosságra, csak azok nem tudták, hogy baj van, akiknek védekezniük kellett volna, mindenki más meg igen.
pláne, hogyha kijön egy típushiba opensource-ra, teljesen normális gondolat a rossz bácsiktól megtesztelni, hogy ugyanez a hiba van-e zárt forrásban.
-
#80
Jim Tonic
nagyúr
Döglött Róka
#77
válasz
Döglött Róka
#77
üzenetére
Szerintem arra volt kíváncsi, hogy miből tudod megállapítani, hogy a fél éves elhallgatás kisebb károkat okozott, mint az, hogy nyilvánosságra hozták, és tudtál mit lépni. Főleg szervereknél.
Mert ugye attól, hogy nem tudunk róla, hogy kiderült-e vagy kihasználták-e, még nem jelenti azt, hogy nem történt meg. Ha titokban tartották, alighanem a betörések is titokban maradtak. -
#78
emvy
félisten
Döglött Róka
#77
válasz
Döglött Róka
#77
üzenetére
Nem hiszem, hogy ez az oka annak, hogy nincs kint. Egyebkent lehetne.
-
#77
Döglött Róka
veterán
emvy
#75
Döglött Róka
veterán
-
#76
dabadab
titán
Döglött Róka
#73
válasz
Döglött Róka
#73
üzenetére
"Akkor megiscsak esszerubben kezeltek fu alatt, mint nyilvanosan az elmult ket nagy open source hibat."
Ez mibol jott ki?
-
Ez egy eleg massziv hir tegnaprol, ami az ITCafen nem uti meg az ingerkuszobot.
http://www.hanselman.com/blog/AnnouncingNET2015NETasOpenSourceNETonMacandLinuxandVisualStudioCommunity.aspx
http://blogs.msdn.com/b/visualstudioalm/archive/2014/11/12/introducing-visual-studio-s-emulator-for-android.aspx
Ingyenes VS =<5 fos vallalatoknak, iOS es Android targetek VS2015-ben, Hyper-V alapu Android-emulator VS2015-ben, a teljes .NET open-source, Linux es Mac tamogatas MS .NET cuccokra (GUI frameworkoket kiveve).
-
#71
emvy
félisten
Döglött Róka
#70
válasz
Döglött Róka
#70
üzenetére
Nyilvanos PoC meg biztosan nincs ra.
-
#79563158
törölt tag
Az előzményhszben éppen azt ecsetelte a hozzászóló burkoltan, hogy a nyílt forráskód jobb, pedig forráskódtól függetlenül minden szoftverben vannak biztonsági hibák. A zárt forráskódú szoftvert is ugyanúgy lehet tesztelni és ha nem egy legacy szoftverről van szó, akkor a fejlesztők általában javítják is a sérülékenységet. (Ha nem javítják akkor meg ugye a vendor trehány és nem kell tőlük többet semmit sem venni, lásd Apple.)
-
cer
tag
De nagyon is sokan elvárják.
( Ugye a hozzáértők tábora egy kisebbséget alkot a népességben. Ehhez talán megemlíthetem azt, hogy 10-ből ha 2 ember tud telepíteni windows-t. )Egyébként állásfoglalásban melletted állok, még ha ez a válaszból nem is látszik. Tudom mire gondolsz. De egy nagyon lényeges pontja az egésznek a pénzes mivolta.
Máskülönben lehet te nem azért használsz opent mert olcsó, de legtöbben azért, mert ingyen van.
-
#66
sh4d0w
félisten
Lapajbacsi
#49
sh4d0w
félisten
válasz
Lapajbacsi
#49
üzenetére
-
#65
sh4d0w
félisten
Lapajbacsi
#49
sh4d0w
félisten
válasz
Lapajbacsi
#49
üzenetére
Neked ezért fizetnek...?
#61 ysengrin: a lehetőség mindenki előtt adott, egyrészt. Másrészt itt Windows hibáról van szó, nem open source hibákról. Harmadrészt pont a ShellShock mutatta meg, mennyire lehet erős az open source. Ha érdekel, a Logout felé vedd az irányt.
Döglött Róka: szívesen.
-
#64
#40553216
törölt tag
Lapajbacsi
#49
#40553216
törölt tag
válasz
Lapajbacsi
#49
üzenetére
A http-n keresztül történő kommunikációt melyik tűzfal szűri?
-
#57
stopperos
senior tag
Lapajbacsi
#49
stopperos
senior tag
válasz
Lapajbacsi
#49
üzenetére
Azért nem olyan boldogító, ha a géped botnet hálózatba kerül.
cer: Mint kiderült egy Windows XP Embedded gépet sikerült virtualizálni, így azt még 2019-ig támogatják.
-
#56
#06658560
törölt tag
Lapajbacsi
#49
#06658560
törölt tag
válasz
Lapajbacsi
#49
üzenetére
"Az lehet, hogy a résen bejut valami féreg, de az ahogy aktiválódik és tevékenykedni kezd, azonnal kijelzi és blokkolja a tűzfal, ezt kéne felfogni. Magát azt a műveletsort észleli irgalmatlanul és megkerülhetetlenül egy normális tűzfal, ami kihagyhatatlan és elengedhetetlen ahhoz, hogy akár a gép fölött átvegyék az uralmat, akár zombi hálózatba tegyék, akár turkáljanak rajta a tudtodon kívül.. "
Látom azért vannak ám komoly sötét fellegek a fejedben.
-
cer
tag
válasz
stopperos
#18
üzenetére
#18 stopperos
Köszi...
Különben mennyire biztos hogy ez az mert némi bizonytalanság támadt köreimben.
Akik windows Update-ből dolgoztak azok IE hibajavítást mondogatnak....
( Sajátgépen holnap megnézegetem. )#39 Tamás88
Tudnál erről bővebben írni. Ilyenre hogy lehet rájönni?
#51 Lapajbacsi
Nem csak a pénznek van értéke.
Egyéként tényleg ne írj le ilyeneket vagy inkább ne írj le semmit. -
-
azopi74
addikt
Kicsit off:
A Visual Studio 2015-ről nincs hír az IT-cafén? Arról egy szó sincs, hogy mostantól mindenféle xamarin nélkül, natívan lehet VS-ban cross-platfomos alkalmazásokat építeni, akár osx-re, linuxra, ios-re, vagy akár androidra? (pontosabban fogalmazva szervesen beintegrálják a xamarint a Visual Studio-ba)
Vagy a szintén ma bejelentett VS Community Edition, amellyel diákoknak, startup-oknak, kkv-knak, független fejlesztőknek és openszósz projektekre ingyen lesz a Visual Studio?
Ha három-négy évvel ezelőtt nyögte volna nekem be valaki a mai Microsoft híreket, körberöhögtem volna.
Ez itt most tényleg már az új, Nadella féle Microsoft.
Nekem valahogy a mai feljeleményekről az jut eszembe, mintha egy erősen kontinentális, hadihajóval nem rendelkező, de brutális légierővel bíró nagyhatalom, miután három évig próbálta sikerteleül lenyomni a ladikjaival a másik két nagyhatalom repülőgéphordozó anyahajókból álló szuper-flottáját, rájött volna, hogy ott érdemes fronton nyitni, ahol erősek, és hirtelen eszükbe jutott volna, hogy igencsak űtős erejű interkontinentális ballisztikus rakétákkal rendelkeznek, amikkel logikus lépés lenne megszórni az ellenfelet, ahelyett, hogy továbbra is a tengeren próbálkoznának a motorcsónakjaikkal. -
#51
Lapajbacsi
aktív tag
bambano
#50
Lapajbacsi
aktív tag
Ez az elmélet. A gyakorlat meg, hogy pl egy Comodo teljesen független a windows rendszerkomponenseitől. Nem lehet így leállítani. Nem lehet a hatalmat átvenni fölötte. Amúgy az Eset is ilyen elvileg.... de azt mondjuk egy kicsit könnyebb. SSL ide vagy oda, értsd meg, ha ilyen könnyű lenne egy ilyen tűzfal programot átverni, akkor amint már írtam, ki lenne már szinte mindenki rabolva a neten. Emberek százmillió kezelnek számlákat és nem érte őket kár... ha ilyen ügyesek lennének az alacsonyabb szintű hekkerek is, akkor mindenki ki lenne rabolva már és minden hekker milliomos lenne már... hogyhogy nem?
-
#50
bambano
titán
Lapajbacsi
#49
bambano
titán
válasz
Lapajbacsi
#49
üzenetére
"Monitoroz és elemez az égvilágon minden hálózati tevékenységet a gépen.": ssl-es kapcsolatokon belül is?
"de az ahogy aktiválódik és tevékenykedni kezd, azonnal kijelzi és blokkolja a tűzfal, ezt kéne felfogni.": azokról a tűzfalakról beszélünk, amire van szolgáltatás a windowsban, hogy kapcsolódjon ki? egy windowsos tűzfalat elküldeni rákászni kevesebb idő, mint amennyi alatt káromkodni kezdesz ezen hsz olvasása során."És nem velünk foglalkoznak, hanem Pentagont és hasonlókat törnek....": mindent törnek válogatás nélkül. arra van a botnet, hogy annyi ip-t átfésüljenek, amennyit csak bírnak, milliószám.
-
#49
Lapajbacsi
aktív tag
Xmister
#45
Lapajbacsi
aktív tag
Látszik hogy nem érted egy jobb tűzfal program működését. Monitoroz és elemez az égvilágon minden hálózati tevékenységet a gépen. Az lehet, hogy a résen bejut valami féreg, de az ahogy aktiválódik és tevékenykedni kezd, azonnal kijelzi és blokkolja a tűzfal, ezt kéne felfogni. Magát azt a műveletsort észleli irgalmatlanul és megkerülhetetlenül egy normális tűzfal, ami kihagyhatatlan és elengedhetetlen ahhoz, hogy akár a gép fölött átvegyék az uralmat, akár zombi hálózatba tegyék, akár turkáljanak rajta a tudtodon kívül.. Ez a misztifikálás, hisztéria és pánik a vírusok, kémprogramok és gép hekkelések körül, beteges.
Tökéletesen nyugodt lehetsz, ha kétféle jó tűzfal van a gépeden, bár persze a résen lehet hogy bejut a hekker ill. a programja, azonban nem fog tudni semmit az égvilágon csinálni, mert azonnal bejelez a tűzfalad.... egészen nyugodtan el lehet ezt hinni, és no para... ha ez nem így lenne, akkor már az égvilágon mindenkit kiraboltak volna a neten aki számlát kezel pl
Való igaz a legprofibb hekkerek átmennek bármin. De könyörgöm, nekik meg nem kell a Microsoft szánalmas pitiáner kis biztonsági rése.. ilyen rés nélkül is bejutnak, ha akarnak..!!! Nos ilyenekből meg van a bolygón pár száz! És nem velünk foglalkoznak, hanem Pentagont és hasonlókat törnek.... Azonban egy ilyen hekker, ha betör hozzád, akkor valószínű lefagy a géped és amíg mojolsz vele, hogy mi történt, újraindítod stb, addig le is szedi róla, ami neki kell. Ezek a profik szinte bárhová betörnek és szinte semmilyen tűzfal nem véd ellenük, Azonban nem törtnek be az átlagemberhez. (milliárdosok, nagyvállalatok, kormányzati hivatalok stb a céljaik, ahol nagyot lehet kaszálni, nem érdekli őket a piti ezer euród...)
A zombihálózatokat üzemeltető és vírusokat terjesztő adathalász és egyéb kiber bűnözők pedig fényévekre vannak az említett profi hekkerektől. Éppen ezért az ő amatőr szutykaiktól abszolút véd a jó tűzfal és vírusvédelem... keep calm.. -
#47
CPT.Pirk
Jómunkásember
Lapajbacsi
#43
CPT.Pirk
Jómunkásember
válasz
Lapajbacsi
#43
üzenetére
Ilyesmit ne írj le, mert még valaki elhiszi!
-
#45
Xmister
senior tag
Lapajbacsi
#43
Xmister
senior tag
válasz
Lapajbacsi
#43
üzenetére
Ezt gondold át mégegyszer.
-
#44
Gdi
senior tag
ImpersonatoR
#1
Gdi
senior tag
válasz
ImpersonatoR
#1
üzenetére
Inkább az, hogy a honap második keddje van (volt).
-
#43
Lapajbacsi
aktív tag
Lapajbacsi
aktív tag
Ezek a rések, soha nem teszik hozzá gusztustalan és sunyi módon, hogy csak a natúr Winfosra vonatkoznak. Ha nincs semmi védelmed, csak akkor vannak.
Ha XP-d van, felraksz egy jó tűzfalat és vírusvédelmet (pl a Comodo-t és a Nod32-őt) és minden ilyen rést befoltoznak... -
#41
redwhite78
aktív tag
redwhite78
aktív tag
Nekem fel sem dobja ezt a frissítést. Azt írja minden friss és megnéztem ezt még nem telepítette (KB2992611). Ennek mi lehet az oka? (win7 pro 32bit)
-
-
fsb1000
nagyúr
A hir lényege, hogy végre cseréld le az XP-det. Mert most nagyon megjárod ha nem ezt teszed.
.
Magyarországi KKV-k jelentős mennyiségben használnak még jogtiszta vagy nem annyira tiszta XP-ket, amelyeket a korábbinál nagyobb arányban fognak jogtisztára cserélni. És nem csak a géppark kiöregedésével, hanem mert a csapból is az folyik hogy az XP már nem biztonságos. -
buherton
őstag
Júúúúúúj, atya Úristen és ti még tényleg zárt kódot használtok?
De hát ez zárt kód, amiben elképzehetetlen, hogy bármilyen hiba benne legyen, hiszen ez zárt és ezt rendesen alkalmazott fejlesztők tartják karban, akik minding mindenre gondolnak, hiszen ezért zárt a forrás. Minek nekünk open source, ha ez sokkal jobb, és biztosan tudjuk, hogy valakik ellenőrzik? Így esélyt sem adva olyan hibáknak, amik már 19 éve benne vannak. Sőt az opennel ellentétben, itt azonnal tájékoztatnak és már aznap jön ki a javítás, mert a biztonság az első, illetve a felhasználók, akikért dolgoznak. De várjunk csak, akkor valami bibi van... Az Apple-nél jövőre javítanak egy kritikus hibát.
-
#33
sh4d0w
félisten
Döglött Róka
#6
sh4d0w
félisten
válasz
Döglött Róka
#6
üzenetére
Te valamit nagyon benéztél:
2014-09-12 16:10:35 +0100
Stéphane Chazelas reports the vulnerability in bash to Chet Ramey (the lead bash developer) and the security contacts of Debian, Red Hat, Ubuntu and Mandriva (SUSE was added later). This included “details of the bug and the SSH and HTTP (Apache header) vectors and mitigation and a bit fat warning that it was very serious and not to be disclosed”. This newly-found vulnerability was assigned the identifier CVE-2014-6271. Stéphane Chazelas found this vulnerability in the morning of the same day (2014-09-12 in the UK), after reflecting on an earlier vulnerability he had reported in libc (CVE-2014-0475) that had involved environment variables and was aggrevated by design choices in bash. As is routinely done, release of details was briefly embargoed. Private discussions were held about the best way to solve the problem, and patches were developed by the bash developer Chet Ramey for a planned coordinated announcement. There were conflicting reports about the date; the dates and other information reported by Stéphane Chazelas himself are used here (because he is a primary source). The article “Stéphane Chazelas: the man who found the web’s ‘most dangerous’ internet security bug” by Ben Grubb, The Sydney Morning Herald, September 27, 2014, provides some interesting early information, but it includes an incorrect date of 2014-09-09 as the report date, and it also incorrectly claims that the previous vulnerability Chazelas reported was in bash (it was actually in GNU libc, and merely aggrevated by bash functionality). The article “Security Experts Expect ‘Shellshock’ Software Bug in Bash to Be Significant” by Nicole Perlrothsept, The New York Times, 2014-09-25 gives the correct Shellshock report date, 2014-09-12.
2014-09-14 14:29:48 +0100
Stéphane Chazelas proposes that this vulnerability be named “bashdoor”. However, this proposed name is not mentioned in early announcements of the vulnerability, and in the end this name does not catch on.
2014-09-16 22:00:02 -0400
Chet Ramey has all final (before disclosure) fixes for the current and all past versions of bash back to 3.0 by 2014-09-16. Source: Stéphane Chazelas.
2014-09-22 07:16:35 +0200
Florian Weimer notifies the private PGP-re-encrypting distros list with subject “CVE-2014-6271 in bash”. It had no detail, but instead stated, “At 2014-09-24 14:00 UTC, we are going to disclose a significant security vulnerability in bash. Please contact the Debian security team... to receive details and upstream patches. Today, this alias will be staffed at least until 21:00 UTC (13:00 PDT).” This was later confirmed by Solar Designer.
2014-09-24 16:05:51 +0200
Vulnerability announcement released to the public, as planned, as CVE-2014-6271, a few minutes after the established embargo time of 2014-09-24 14:00 UTC. This announcement was reported on the oss-security mailing list by Florian Weimer (Red Hat Product Security Team) in a short and long announcement. At around the same time Chet Ramey releases official patch 25 for bash 4.3 (the current version), aka “bash43-025”, along with related patches for past versions of bash, that is intended to fix the vulnerability. Distributions who had participated in the coordinated disclosure released their patches as well. This public report reflected the original understanding of the problem: “environment variables are processed: trailing code in function definitions was executed, independent of the variable name. In many common configurations, this vulnerability is exploitable over the network.” Up to this time this has been a typical coordinated disclosure process; it will now change into a full disclosure process. forrás
Senki nem vágyott 5 perc hírnévre és az eredetileg megtalált problémára kiadták a javítást a bejelentéskor. Csak ezután kezdett el Tavis Ormandy és a többi biztonsági szakember foglalkozni a bash parserrel és kiderült, hogy abban még van 5 hiba, amivel probléma generálható.
-
#27
DRB
senior tag
Namelesske
#24
DRB
senior tag
válasz
Namelesske
#24
üzenetére
850 mega? Az a gép mostanában nem kapott frissítéseket. Egyébként a szóban forgó frissítés ~ 5 mega, ha ettől lehal egy gép, az kb. a Pentium II eleje korszakból származhat, azért azt már le kéne cserélni.
-
#24
Namelesske
addikt
Namelesske
addikt
A frissítés zökkenőmentessége is megkapja a -9.3-mat a legtöbb ismerősöm szenved miatta, szarakodik a régi gyenge gépe, van akinek el sem indult ma a Windows. Nekem szerencsére semmi hiba nem volt, sőt meglepően gyorsan települt a 850 mega. (Office is frissített)
Shellshock után szerintem STFU mindenkinek.
-
Gregorius
őstag
-
-
#16
Jim Tonic
nagyúr
gyurkikrisz
#14
válasz
gyurkikrisz
#14
üzenetére
Azért jó, ha tapsikolós szmájlival kezdenek egy hozzászólást, mert akkor az utána levő részt egyből át lehet ugrani. Gondolom, tisztában vagy azzal, hogy csak az titok, amit egy ember tud.
-
#15
bambano
titán
gyurkikrisz
#14
bambano
titán
válasz
gyurkikrisz
#14
üzenetére
pontosabban fogalmazva nem tudunk semmit arról, hogy kik ismerték a hibát.
-
#12
bambano
titán
gyurkikrisz
#9
bambano
titán
válasz
gyurkikrisz
#9
üzenetére
rakd össze a leírt mondatokat, amikre reagáltam:
"A sebezhetőséget az IBM kutatói fedezték fel még idén májusban. A Microsoft azonban nem akarta nyilvánosságra hozni a hibát, ameddig nem sikerül kijavítani azt."
erre írta (#6) Döglött Róka: "Itt az a nuansznyi kulonbseg, hogy a shellshock-nal az 5 perc hirnevert a megtalalo korbekurtolte a netet, de folt persze meg nem volt."vagyis összességében az az állítás (amelynek a tény része igaz), hogy:
- a shellshock bugnál előbb derült ki a hiba, és csak utána lett javítás
- itt meg titokban tartották a hibát a felfedezése után fél évig, mire meglett a javítás. (teljes titokban.. Mr. Teufel).ez azt jelenti, hogy amikor kiderült a hiba, a shellshocknál nem volt javítás rá, DE lehetett védekezni ellene, szemben azzal, amikor rájöttek erre a hibára és titkolták. Tehát ha mégis kiszivárgott volna a hiba, neadjgates eladták volna az nsa-nak, akkor egy fél évig egy zárt kör számára átjáróház lett minden gép.
-
alldaybig
tag
és most akkor mindenki azt hiszi h ettől függetlenül aki akar nem fér a gépéhez?
XDDDDDcsak lássa a számítógéped/telefonod/tableted/szervered/pos terminálod/v. aktuális index.hu-ról hírekkel ellátott kávéautomatád a világhálót... és nem vagy védve
egyetlen védelem az ha beköltözöl egy barlangba
-
afk22
tag
Nem ertem az ertetlenkedest... Azt sem lehetett tudni publikusan, hogy van a hiba, tehat senki sem kereste, tehat valojaban sebezhetoseg szempontjabol ugyan az, mint a hiba megtalalasaig eltelt 19 ev. Most hogy lehet tudni hogy van ilyen hiba nagyobb a veszely, hiaba van ra patch, mert tobben ramozdulhatnak es megkereshetik hogyan is lehet kihasznalni, es a meg nem frissitett gepeket megprobalhatjak megfertozni. Tehat nem tul ertelmes, amit irnak itt paran, hogy milyen szemetseg...
-
#8
bambano
titán
Döglött Róka
#6
bambano
titán
válasz
Döglött Róka
#6
üzenetére
viszont volt rá kerülő megoldásként védekezési mód. tehát a shellshocknál tudtál védekezni ellene, mert hamar megtudtad, itt meg nem, mert titkolták.
nem is annyira nüansznyi a különbség.
-
#1
ImpersonatoR
addikt
Akkor ez volt a mai update oka
![;]](http://cdn.rios.hu/dl/s/v1.gif)
De hát ez zárt kód, amiben elképzehetetlen, hogy bármilyen hiba benne legyen, hiszen ez zárt és ezt rendesen alkalmazott fejlesztők tartják karban, akik minding mindenre gondolnak, hiszen ezért zárt a forrás. Minek nekünk open source, ha ez sokkal jobb, és biztosan tudjuk, hogy valakik ellenőrzik? Így esélyt sem adva olyan hibáknak, amik már 19 éve benne vannak. Sőt az opennel ellentétben, itt azonnal tájékoztatnak és már aznap jön ki a javítás, mert a biztonság az első, illetve a felhasználók, akikért dolgoznak. De várjunk csak, akkor valami bibi van... 
Viszont nem adták ki, hogy hiba van, hogy minden jöttment hacker kihasználja. Mindennek két oldala van, csak te az ehyiket nem látod
Új hozzászólás Aktív témák
- Nintendo Switch 2
- A fociról könnyedén, egy baráti társaságban
- Path of Exile 2
- Audi, Cupra, Seat, Skoda, Volkswagen topik
- Fujifilm X
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Apple Watch Ultra - első nekifutás
- Wise (ex-TransferWise)
- AMD Ryzen 9 / 7 / 5 / 3 5***(X) "Zen 3" (AM4)
- Milyen billentyűzetet vegyek?
- További aktív témák...
- IPhone 16 Pro max 256GB gyári független 2026.02.26. Apple jótállás
- Lenovo LOQ (15IAX9) - Intel Core i5 i5-12450HX, RTX 4060 (3db érhető még el)
- FÉLÁRON! Fujifilm Instax Mini 12 instant fényképezőgép + 2x10 mini film - Új, bontatlan!
- Dell Latitude 5320 -60% "Kis Gamer" Üzleti Profi Ultrabook 13,3" i5-1145G7 8/256 FHD IRIS Xe
- Apple IPad pro 12.9 4th gen 256GB wifi+sim 97%-os Gyári akku
- HP ZBook 15 G6 i7-9850H 32GB RAM 1000GB SSD NVIDIA Quadro T2000 15.6 FHD 1 év garancia
- LG 27GR95QE - 27" OLED / QHD 2K / 240Hz & 0.03ms / NVIDIA G-Sync / FreeSync Premium / HDMI 2.1
- Apple iPhone 12 Pro Max /128GB / Gyári független / 12Hó Garancia / 83% aku
- Hp Prodesk 600 G3/ G5/ G6 SFF/ i5 8-9-10 gen / Elitedesk 800 G4 /Win11- Számla, garancia
- Samsung Galaxy A33 5G 128GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: FOTC
Város: Budapest