A log4j-ről csinált videot a bhis is. [link]

Buliban hasznos! =]

Kedvencem a mai napról "the floor is java".

Buliban hasznos! =]

A PGP titkosítással érkező leveleket ti hogyan kezelnétek? Egyik oldalról ott van, hogy e2e encryption kéne, hogy tényleg csak a fogadó fél gépén lehessen megnyitni, még a belső hálón is titkosítva menjen, másik oldalról meg ott van, hogy amíg nincs feloldva a titkosítás, addig nem tudunk víruskeresést tolni a csatolmányokra, szóval az összes hálózati védelmi rétegen lazán átmegy.

[ Szerkesztve ]

Buliban hasznos! =]

Csak az marad, hogy ott scannelsz, ahol feloldják a titkosítást. A másik oldalon meg tréninget biztosítasz és adminisztratív korlátokat állítasz fel.

https://www.coreinfinity.tech

Nem lehet valahogy sandboxolni ezt? Pl egy gépre érkezhetnek az ilyen levelek, és az külön alhálózaton van, vagy ilyesmi?

A másik, hogy log4j-vel kapcsolatban ti milyen gyakran használt alkalmazásokat találtatok, amit frissíteni kellett? Muszáj lesz ráállnom, mert outsourcolva van az informatika jelenleg és mindent leszarnak kb. Próbálom elérni, hogy bízzunk meg inkább helyi embert vele, akivel tudok együtt dolgozni, meg leginkább megjelenik, ha kérjük...

[ Szerkesztve ]

Buliban hasznos! =]

A probléma az, hogy egy helyre összezsúfolni a privát kulcsokat nagyon nem jó ötlet. Windows-ban van sandbox (egy üres vm), de egyrészt hw-követelménye van, másrészt nagyon kényelmetlen, plusz tanítsd meg Jucikának, hogy indítson egy ilyet, majd abban oldja a titkosítást, végezzen scant... Szerintem esélytelen.

Log4j: itt nincs exkjúz, mindent patchelni kell, ami használja a sérülékeny verziókat. Hatékony megoldás, ha a kódbázis githubon van, ott könnyű scannelni, mi használja.

https://www.coreinfinity.tech

Az világos, de ha az ember akar egy menetrendet, akkor az elejére a gyakran használtakat állítja. Eleve nagyobb eséllyel azokhoz is jönnek ki a patchek először.

Buliban hasznos! =]

Ilyen súlyos hibánál priorizálni legfeljebb úgy lehet: melyik rendszer publikus, melyik nem, de mindegyiket javítani kell, kivétel nélkül. A publikusaknál ASAP - ez egyébként egybeesik a Te véleményeddel, mert amelyik publikus, annál alap, hogy használják is.

[ Szerkesztve ]

https://www.coreinfinity.tech

Ja, igaz.

Buliban hasznos! =]

Erintett rendszerek kozul risk assessment alapjan lodd be, hogy melyik assetek a legfontosabbak es azokat patcheld eloszor. Az internet facing illetve az internetrol erkezo adatokkal erintkezo hostok eseten a legnagyobb a likelihood az ertekes asseteknel meg az impact. SaaS meg PaaS eseten szerencsere a provider valoszinuleg mar patchelt.

sh4d0w: Ezzel a sajat alkalmazasokat lefedi az ember (illetve tranzitiv dependenciak eseten azokat sem), de sajnos nincs mese vegig kell menni az asset inventoryn es vegignezni, hogy melyik alkalmazas serulekeny.

Ez így van, én sem állítottam mást.

https://www.coreinfinity.tech

úgy kell, hogy egy monitoring key-t kötelezően hozzá kell adni, és akkor majd a köztes réteg is meg fogja tudni nyitni:
https://stackoverflow.com/a/28206835/8154543

JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...

Köszönöm!

Buliban hasznos! =]

Wow, köszönöm én is.

https://www.coreinfinity.tech

Itt a log4j lista, ha valakinek kellene még: [link]

Buliban hasznos! =]

Mondjuk ez se teljes. Jó lenne valami központi szolgáltatás, ahol összegyűjtik, hogy melyik sebezhetőség milyen termékeket érint. Igazán jó akkor lenne, ha lehetne queryzni egy meglévő listával. A gond csak az, hogy nagyon nagy hatalmat adnánk annak, aki karbantartja ezt a listát, és hát mindenki is ezt a szolgáltatást támadná.

[ Szerkesztve ]

Buliban hasznos! =]

Na így egész napos olvasgatás után nekem úgy tűnik, hogy bizonyos szerverek és ritkábban hálózati eszközök érintettek általában ezzel a log4j-vel. A munkaállomásokra annyira nem jellemző a dolog, mert inkább a szervereken szokás naplózni. Sok helyen pl java sincsen a munkaállomásokon. Ami valamennyire meglepő volt a listákról az nekem a PowerChute Business Edition. Ez az APC szünetmentes tápegységekhez tartozó szoftver. Még az Ubiquity-nek egy alkalmazása érintett, de szerintem nekünk az sincs fent. CPE-ket kell majd néznem, úgy világosabb, hogy mi micsoda. Egyelőre semmit nem találtam, ami érintett lenne.

[ Szerkesztve ]

Buliban hasznos! =]

Egy önkormányzati hivatalban ahol néha besegítek, ott az Ubiquiti controller meg a VMware vCenter ami érintett.
A controllernél szívás, hogy régi AP-val mennek, és az upgrade után meg nem fogom tudni már módosítani a konfigot
Vehetnek új AP-kat jövőre, igaz ezek régiek, de hibátlanul mentek.
A weboldalról még nem tudják, hogy érintett-e igaz az kint fut valami wordpress-en.

| MCSE+M/S, MCITP, VCP6.5-DCV - ''Life can be hard, but Scooter is harder :)'

Nekünk is az Ubiquity a kérdés még. Holnap ránézek. Igazából hosszú távon én szeretném, ha csak vendég wifi lenne és mindenhol máshol kábelezni kellene. Az egyetemi tanárom szerint a wifi nem tehető biztonságossá, és úgy kell kezelni, mintha egy netes kávézóban lenne az illető, nem a hivatal épületében. Ja a weboldal hasonlóan frankó nálunk is, de annál jobb is, hogy nem saját szerveren fut.

[ Szerkesztve ]

Buliban hasznos! =]

Papíron szép a no-wifi ötlet, látszi, hogy egy egyetemi tanár agyából pattant ki
Gyakorlatban nem valósítható meg, és azért cert alapú hitelesítéssel + AD auth-al azért elég biztonságos.

| MCSE+M/S, MCITP, VCP6.5-DCV - ''Life can be hard, but Scooter is harder :)'

+1. A kabelezes port security nelkul csak hamis biztonsagerzetet ad es arra is ott a MAC spoofing.

Nem mondta, hogy no wifi, csak azt, hogy úgy kell kezelni, mintha kintről jönne a kérés, tehát VPN, tűzfal, stb.

A no wifi nekem egyszerűbb, mert nem kell ezekkel kínlódni, és a gépek nagy része amúgy is asztali gép, a maradék néhánynak meg nagyon egyszerű behúzni egy kábelt. Azért kíváncsi vagyok, hogy a gyakorlatban miért ne lenne megvalósítható nálunk. Én nem látom semmi akadályát. Egyébként sem no wifit írtam, vendég wifi tőlem lehet más VLAN-on.

[ Szerkesztve ]

Buliban hasznos! =]

Hát azért más, ha be kell jönniük az épületbe rádugni a gépet a hálózatra, mintha leülnének a hivatal elé, és onnan törnék fel a hálózatot wifin keresztül. Pláne hogy most egy volt katona, rendőr csajt akarunk felvenni a portára.

[ Szerkesztve ]

Buliban hasznos! =]

Ez kb addig működik, amíg a polgi / jegyző ki nem veri a balhét, hogy márpedig ő laptopról fog dolgozni és oldja meg az informatikus. (És akkor a sok veszélyes telefonról nem is beszéltünk ami sok esetben a belső hálózatra kötött wifire csatlakozik.)
Legalább 3 VLAN-nak illik lennie egy önkornál is.
Kockázatelemzés után mi a 802.1x-et szoktuk javasolni a belső hálózaton, a vendég wifire külön szabályok, a management hálózathoz meg csak vagy vezetéken, lehet becsatlakozni meghatározott portról, vagy VPN-en keresztül.

Most kezdődjék a tánc! - mondta a papagáj és berepült a ventilátorba.

Semmi akadálya, hogy laptopról dolgozzon. Most is úgy megy az emberek egy részénél. Bármilyen meglepő, egy UTP kábelt rá lehet dugni egy laptopra is.

Buliban hasznos! =]

Az egyetemi tanárom szerint a wifi nem tehető biztonságossá, és úgy kell kezelni, mintha egy netes kávézóban lenne az illető, nem a hivatal épületében.

Jó nagy b*rom lehet az illető... Nem véletlenül tanít, és nem dolgozik. Ellenpont: az egyik tanáromat az EIV képzésen úgy hívták, hogy Frész Ferenc (aki bár finoman fogalmazva is ellentmondásos figura, letett már annyit az asztalra ebben az iparágban, amennyiről az egyetemi tanárok kilencvensok százaléka legfeljebb csak álmodhat...); nos ő tett egy olyan kijelentést úgy 2014-2015 tájékán, amire többen felkaptuk a fejünket: egy jól konfigurált Aruba hálózat szerinte biztonságosabb (sic!) mint a LAN... Ezen nyilván lehet vitatkozni, de az egyetemi tanárod szerintem még csak nem is hallott mondjuk a Radius-ról, és szerinte a MAC Adress szűrés a max. amit lehet tenni egy wifi hálózat biztonságossá tételéhez... Na jó, talán a WPA2-PSK-ig is eljutott - de hogy tovább nem, azt szinte biztosra veszem...

[ Szerkesztve ]

"Bonyolult kérdésre egyszerű választ keresni helyénvaló, de ritkán célravezető megoldás" (Wayne Chapman)

Az OTP-nél ő csinálja az információbiztonságot. Egyébként tart katonáknak is kibertámadásos képzéseket még emellett. Lehet amúgy téged is oktatott NKE-n annak idején. Mondjuk azóta mióta végeztél szerintem változott valamit az oktatói gárda.

[ Szerkesztve ]

Buliban hasznos! =]

Oké, akkor menjünk bele a részletekbe.
1. Egy netes kávézóban nincs WPA, full titkosítatlanul közlekednek az adatok az éterben. Nincs authentikáció (általában), a netre felcsattanó felhasználókat nem lehet azonosítani.
2. A wifi feltörése illetve ennek megkísérlése (nem az otthonira gondolok) az esetek majdnem 100%-ában úgy történik, hogy "lelökik" a wifiről az adott klienst, ami megpróbál újracsatlakozni, ugyanakkor megpróbálják elnyomni a valós AP-t, hogy egy kalóz AP-ra csatlakozzon az adott kliens, és így, közbeékelődve szereznek további infókat a töréshez (pl. felhasználónevet, jelszó hasht). Egy normális enterprise wifi megoldás ezt képes megakadályozni illetve jelezni is. Szóval igenis biztonságossá tehető a wifi: arról nyilván lehet vitatkozni, hogy egy normális (!) kábeles kapcsolathoz képest hány százalékban, de hogy a netes kávézóval vont párhuzam erős marhaság, az egészen biztos.

[ Szerkesztve ]

"Bonyolult kérdésre egyszerű választ keresni helyénvaló, de ritkán célravezető megoldás" (Wayne Chapman)

1. Értem, hát én meg abból indultam ki, hogy WPA2 van egy netes kávézóban, de ezt a részét én raktam hozzá a hasonlatnak, sosem jártam ilyen helyen, nem is fogok. A lényeg az lett volna, hogy úgy kell értelmezni a helyzetet, mintha nem is abban az épületben lennél, hanem az interneten keresztül próbálnád elérni nem biztonságos csatornán keresztül.

2. Hát ő konkrétan azt mondta, hogy a WPA2 is törhető néhány nap alatt, a WPA pedig 10 perc. Szerinte a wifi szabványokat annak idején nem gondolták át biztonsági szempontból, és emiatt nem tehető biztonságossá a technológia szemben a mobilinternettel.

Úgy olvasom, hogy a legegyszerűbb módszer a handshake elkapása és a jelszó törése dictionary attack-al, újabban már PMKID-s módszer is van a jelszó megszerzésére, ami jóval gyorsabb: [link] Amit te írsz, az már egy fokkal bonyolultabb.

Ha mást nézek, és nem a jelszóra koncentrálok, akkor minimum egy esetben ugyanazt mondták, mint ő, hogy a szabványokkal van a gond: [link]
"According to the researchers, the weaknesses are in the Wi-Fi standard itself, and not in individual products or implementations. Therefore, any correct implementation of WPA2 is likely to be affected. To prevent the attack, organizations must update affected products as soon as security updates become available."

Buliban hasznos! =]

A PMKID eseten is ugyanugy brute forceolni kell, csak kevesebb elofeltetele van a tamadasnak. De sok sikert a HMAC-SHA1 brute forcehoz, jo lesz az par nap helyett par evnek. PSK eseten a valoszinubb risk az, hogy kiplakatoljak a userek a kulccsal a belso tereket.

Egyebkent szerinted mi a vegkimenetele annak, ha valaki megtori a wifit? Remelhetoleg van rendes patch management, megfelelo serviceken autentikacio es alkalmazasszinten minden protokolon titkositas.

Ha feltörik a wifit és biztonságosnak gondoljuk, akkor bejutnak a belső hálóra azon keresztül anélkül, hogy az épületbe betették volna a lábukat. Onnan tudnak tovább dolgozni. A végkimenetelt nem lehet ennyi info alapján megjósolni.

Állítólag van vagy nemrég volt ilyen magyar büntetőügy, amiben az egyik cég beállt furgonnal a másik parkolójába, és onnan wifin keresztül lelopta a céges titkokat. Keresővel viszont nem találom. Gondolom ennél az esetnél azért nem volt minden rendben a biztonság többi részével sem, pl a fizikai biztonság is érdekes, ha napokig állhat ott egy furgon és nem tűnik fel senkinek.

[ Szerkesztve ]

Buliban hasznos! =]

Megfelelően hosszú (értsd: legalább 12 karakter), és nem szótárazható jelszó esetén, még egy számottevő géppark esetén is évekbe telne brute force-olni egy wifi jelszót (de még egyszer: Radius szerveres authentikációból kellene kiindulni). Ezen túlmenően, csillió intézkedéssel lehet csökkenteni a kockázatot (pl. wifi teljesítmény visszavétele, hogy az utcáról már ne lehessen rácsatlakozni; wifi kikapcsolása munkaidőn túl stb.).

"Bonyolult kérdésre egyszerű választ keresni helyénvaló, de ritkán célravezető megoldás" (Wayne Chapman)

Alapvetoen az az "uj" paradigma az informaciobiztonsagban az, hogy nem gondoljuk biztonsagosnak a belso halozatot, hanem mindent ugy kezelunk, mintha kompromitalodott volna. Ha igy gondolkozol a halozatrol akkor tokmindegy, hogy az also ket halozati reteg kabel vagy radiohullam.

Jawohl, szvsz a zero trust és az SDN nagyon sokat segíthet.

https://www.coreinfinity.tech

Ez egy dolog, de nyilvánvalóan tovább csökkenti a kockázatot, ha nehezebben tudnak betörni a hálózatba, és ha megoldható, akkor emiatt érdemes meglépni. Nálunk például nincs olyan hatalmas igény arra, hogy wifiről el lehessen érni a belső hálót.

Buliban hasznos! =]

Általában ezeket a támadásokat nem a pw bruteforce-olásával oldják meg, hanem pl side-channel attack-kel. Vagy sebezhető FW-rel futó eszközök ellen a hardvert (vagy a wifi-implementációt) támadva. Vezetékes net esetén a még mindig hozzá kell férni a vezetékhez - vagy annak közvetlen környezetéhez.

JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...

A wifi töréshez is egészen közel kell lenni...
Egyébként wifi side-channel attack példára némi keresés után csak WPA-TKIP elleni támadásra bukkantam, ami meg ugyebár nem annyira tekinthető biztonságos implementációnak. Nyilván sérülékeny FW az támadható, de azért tételezzünk fel egy biztonságos wifi hálózatnál megfelelő patch managementet is.

"Bonyolult kérdésre egyszerű választ keresni helyénvaló, de ritkán célravezető megoldás" (Wayne Chapman)

Már amelyiken van UTP csatlakozó... (Mondjuk egy almás gép vagy egy ultarabook már nem biztos ennyire egyértelmű.)
Mellesleg a laptopot általában azért akarnak a vezetők, hogy kevesebb legyen a madzag, meg kényelmesen dolgozzanak, ezért az UTP kábel dugdosása már elvi problémákat szülhet.

#782 Etikus hackelés keretében ilyet már mi is csináltuk, hogy a szemközti parkolóból hackeltük a belső hálót. (Annyival egyszerűbb dolgunk volt nem kellett wifi jelszót törni, mert kint volt a belső faliújságon a titkárnő melletti falon.)

Most kezdődjék a tánc! - mondta a papagáj és berepült a ventilátorba.

Üdv Urak!

MIntegy kéttucat (vagy több) mobiltelefon vonatkozásában (értelemszerűen konkrét típusokról van szó) kellene gyorsan megtudnom, hogy hivatalosan támogatottak-e még a gyártó által (azaz van-e rájuk security update), vagy senem.
Van valami oldal ahol ezek össze vannak szedve (hogy mely készülékeknek járt már le esetleg a hivatalos gyártói támogatása)?

"Bonyolult kérdésre egyszerű választ keresni helyénvaló, de ritkán célravezető megoldás" (Wayne Chapman)

Üdv!

endoflife.date -et nézted már?

(Mellesleg azt hiszem ilyen tekintetben az Apple-ön és Google-ön kívül aligha vehetőek mások komolyan.)

[ Szerkesztve ]

Ismét keresünk embert, ezúttal SOC üzemeltetői-logelemzői szerepkörbe, legalább 2-3 év gyakorlattal, erős Linux tudással, IT security érdeklődéssel (tehetséges junior-medior kollégában gondolkodunk leginkább, de más is jöhet). Heti 2 nap home office, 20%-os évi prémium stb.
Részleteket szívesen megosztom PM-ben.
Ha tudtok valakit, ne tartsátok magatokban...

"Bonyolult kérdésre egyszerű választ keresni helyénvaló, de ritkán célravezető megoldás" (Wayne Chapman)

A következő problémával szembesülök: egyszerű network scanneléssel nem tudom felfedezni a Windows 10/11 gépeket. Sem nmap, sem saját magam által írt scannerek nem találják meg ezeket, van valakinek ötlete, mit lehet tenni?

https://www.coreinfinity.tech

Windows vagy linux gépről? Ping sem megy? NSLOOKUP esetleg?

JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...

Biztos, hogy a hálózaton vannak? Eddig működtek ezek, csak mostantól nem?

Buliban hasznos! =]

Linuxról, de még néhány szó a környezetről:

(Többek között) network discovery eszközöket fejlesztek (nem megyek bele, miért nem az nmapet használom), a célpont gépek nyilván virtuálisak (de egyébként a probléma valódi fizikai géppel is fennáll). Többségük Linux, de pontosan a megfelelő tesztelés miatt Windows 10 és 11 is van a virtuális környezetben (VMWare).

Nos, a Windows 10/11 sem pingre, sem nmap scanre, sem scapy vagy socket modulban használt kapcsolódási kérelemre nem reagál (ami alapvetően ugye jó, mert megnehezíti a támadó dolgát, másfelől meg megnehezíti a security-s dolgát, mert nem látja a védendő assetet).

Mindegyik Windows default telepítés, semmilyen extra védelmi szoftver nincs rajtuk, csak a beépített Defender - van mód arra, hogy megtaláljam ezeket a rendszereket? Ua. hálózatban a Linuxos gépeket látom (a Fedora szerver kivételével - ami megint csak érthető, de ennek majd később megyek utána).

[ Szerkesztve ]

https://www.coreinfinity.tech

Ha ez alapból ilyen, akkor 100%, hogy google-el is találsz hasonlót. pl [link] De ez inkább hálózati probléma egyébként, mint szekus, vagy a kettő együtt.

[ Szerkesztve ]

Buliban hasznos! =]

Nyilván ha találtam volna hasonlót, onnan tájékozódom, nem itt kérdezem a nagyérdeműt

Persze lehet, hogy csak rossz keresőszavakat használtam.

https://www.coreinfinity.tech

Hát én azt látom, hogy a pingelés alapból blokkolva van a Windows tűzfal által. Nem tudom mióta van ez, én sem tapasztaltam még. Tavaly októberi cikkekben látom. Az ICMP pinget kell engedélyezni a tűzfalon, és elvileg mennie kéne. De ez így 1 perc google, gondolom próbáltad már. Ha nem ennyire triviális, szívesen rákérdek facebook csoportban. Ott valamivel többen látják.

[ Szerkesztve ]

Buliban hasznos! =]

De pont ez a lényeg: nem engedélyezed az echo reply-t, nem könnyíted meg a támadó helyzetét azzal, hogy felismerhetővé teszed a potenciális célpontokat.

https://www.coreinfinity.tech