Új hozzászólás Aktív témák

• #34 floatr veterán atok666 #33

  Új Válasz 2021-12-16 14:20:01 #34

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  floatr

  veterán

  válasz atok666 #33 üzenetére

  "When exactly is the vulnerability exploitable?
  All of the following conditions must apply in order for a specific Java application to be vulnerable:
  - The Java application uses log4j (Maven package log4j-core) version 2.0.0-2.14.1
  - A remote attacker can cause arbitrary strings to be logged, via one of the logging APIs – logger.info(), logger.debug(), logger.error(), logger.fatal(), logger.log(), logger.trace(), logger.warn().
  - (on some machines) The Java JRE / JDK version in use is older than the following versions: 6u211, 7u201, 8u191, 11.0.1"

  Most ez az "on some machines" misztikus, de frissebb verziók esetén ki van kapcsolva a jndi lookup alapból

• #33 atok666 őstag hcl #12

  Új Válasz 2021-12-16 13:48:53 #33

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  atok666

  őstag

  válasz hcl #12 üzenetére

  Egy Java frissites nem oldja meg ezt a konkret gondot. Vagy roszul ertelmezem?

  Atok

• #32 hcl titán floatr #31

  Új Válasz 2021-12-13 22:54:29 #32

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  hcl

  titán

  LOGOUT blog (1)

  válasz floatr #31 üzenetére

  "A külsős szoftverek a nevük ellenére meglepően szutyok minőségűek."
  Jó, azon sem kell meglepődni.

• #31 floatr veterán hcl #30

  Új Válasz 2021-12-13 20:38:53 #31

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  floatr

  veterán

  válasz hcl #30 üzenetére

  A legtöbb hiba a 3rd party komponensekben van, de nem a "java lyukas". Nem tudom, hogy a runtime maga a milliónyi cuccával mennyire számít kirívóan bugosnak, de eddig a legtöbb fejfájást nem az okozta.
  A külsős szoftverek a nevük ellenére meglepően szutyok minőségűek.

• #30 hcl titán Vision #29

  Új Válasz 2021-12-13 19:02:41 #30

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  hcl

  titán

  LOGOUT blog (1)

  válasz Vision #29 üzenetére

  Szerintem arról is, hogy sosem volt túl jól megírva Mondom szerintem, aztán nem biztos, hogy igazam van.

• #29 Vision veterán hcl #28

  Új Válasz 2021-12-13 18:55:32 #29

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Vision

  veterán

  válasz hcl #28 üzenetére

  Egyszerűen csak arról van szó, hogy a Java nagyjából a legnépszerűbb nyelv (enterprise környezetben mindenképp), szóval rengetegen dolgoznak azon, hogy lyukakat találjanak benne. Továbbá számtalan 3rd party lib van, ami potenciális veszélyforrás. Speciel ez a sebezhetőség sem Java hiba.

• #28 hcl titán floatr #27

  Új Válasz 2021-12-13 18:34:47 #28

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  hcl

  titán

  LOGOUT blog (1)

  válasz floatr #27 üzenetére

  És az is igaz, de a Java különösen baromira, persze személyes benyomásom szerint, ha esetleg ez eddig nem lett volna egyértelmű .

• #27 floatr veterán hcl #26

  Új Válasz 2021-12-13 18:17:29 #27

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  floatr

  veterán

  válasz hcl #26 üzenetére

  Ennyi erővel, minden szoftver lyukas

• #26 hcl titán strogov #17

  Új Válasz 2021-12-13 15:33:52 #26

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  hcl

  titán

  LOGOUT blog (1)

  válasz strogov #17 üzenetére

  Mint mondtam, dolgoztam ilyen helyen (nem bankban, hanem nagyobb cégnél szerveradminként, ahol voltak ilyen folyamatok - és compliance is - iszonyatos idióta követelményekkel, és kb. arra volt jó, hogy lassítsa a reakciót).

  "Egy külön csoport foglalkozott azzal, hogy melyik rendszereket lehet szanálni, mert már senki nem használja"
  Nekünk 20+ ezer soros szerverlista volt

  "K&H-ban pl. még ott van törvényi kötelezettség miatt egy rendszer amiből lekérhetőek a hivatalos kárpótlási jegy információk. Ehhez nyilván 25 éve senki nem nyúlt, de ott van."
  Ja, az ilyesmit borzalmasan leválasztani, de azért ez kilóg negatív irányba.

  Szóval nem kifogás, 2 év alatt ahol szándék van, ott végig lehet vinni egy Java updatet. Én is tapasztalatból beszélek.

  @floatr : A Java általában véve lyukas.

• #25 #68216320 törölt tag tomazin #23

  Új Válasz 2021-12-13 13:43:46 #25

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  #68216320

  törölt tag

  válasz tomazin #23 üzenetére

  Persze, úgy gondoltam Köszi.

• #24 ddekany veterán dabadab #20

  Új Válasz 2021-12-13 13:18:00 #24

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ddekany

  veterán

  válasz dabadab #20 üzenetére

  Akkor te se vagy már fiatal, ha így látod. Nagyon rég volt már, mikor Apache egyenlő volt a Apache HTTP Serverrel.

• #23 tomazin veterán #68216320 #8

  Új Válasz 2021-12-13 12:58:00 #23

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  tomazin

  veterán

  válasz #68216320 #8 üzenetére

  Deployolni sem art( ), de elvileg igen.

• #22 floatr veterán dabadab #20

  Új Válasz 2021-12-13 12:53:31 #22

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  floatr

  veterán

  válasz dabadab #20 üzenetére

  A tomcat és az elasticsearch is használja sajnos

  #21 dabadab
  ezzel csak annyi a baj, hogy a frissítéseket általában nem telepítik főleg dockeres setupban

• #21 dabadab titán floatr #19

  Új Válasz 2021-12-13 12:50:48 #21

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  dabadab

  titán

  válasz floatr #19 üzenetére

  Nem marháskodjunk már, hogy "a Java lyukas".

  Persze, ez a mostani nem a JRE hibája, de abban is elég rendszeresen találnak ezt-azt: [link]

• #20 dabadab titán ddekany #18

  Új Válasz 2021-12-13 12:48:16 #20

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  dabadab

  titán

  válasz ddekany #18 üzenetére

  Az Apache egy alapítvány

  Meg - még inkább - egy webszerver, a cím láttán az jutott eszembe, hogy akkor nincs gond, mert ngix van nálunk.

• #19 floatr veterán hcl #12

  Új Válasz 2021-12-13 12:37:37 #19

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  floatr

  veterán

  válasz hcl #12 üzenetére

  Nem marháskodjunk már, hogy "a Java lyukas". Egy szoftverben van sebezhetőség, amit javaban írtak 3rd party komponensnek. Ugyanez volt a commons file uploaddal is.
  Ez az egyik nagy előnye és egyben hátránya is, hogy sok forrásból szármanak komponensek, amiket használsz.

• #18 ddekany veterán

  Új Válasz 2021-12-13 10:59:33 #18

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ddekany

  veterán

  Ezt a címet át kéne sürgősen írni... Ez egy Log4j sebezhetőség. Az Apache egy alapítvány, aminél rengeteg project fut, és nem az alapítvány alkalmazza fejlesztőket, meg úgy általában nagyon kevés központi kontroll van a projektek vezetése felett. Totálisan unfair az Apache-t feketíteni ezekkel. Kb. infrastruktúrát és jogi keretet adnak a projektekhez.

• #17 strogov senior tag hcl #16

  Új Válasz 2021-12-13 10:41:00 #17

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  strogov

  senior tag

  válasz hcl #16 üzenetére

  Egy bankban nem úgy megy az upgrade, hogy éjszaka kitalálod, reggel telepíted. Megfelelési folyamat van amit be kell tartani. Nyilván célszerűen a kintről látható rendszereiket naprakészen tarthatják, de simán benne van, hogy egy elkallódott rendszer ott van valahol.

  Nem írok nevet (multi). Amikor rendszerlistát kértünk akkor csak az IT 3 nyilvántartóból hozta össze a 400+ működő, karbantartott rendszer nevét, és kaptunk egy excel-t is, hogy valójában ezek használjak (~150).
  Egy külön csoport foglalkozott azzal, hogy melyik rendszereket lehet szanálni, mert már senki nem használja ... és nagyon sok melójuk volt.

  K&H-ban pl. még ott van törvényi kötelezettség miatt egy rendszer amiből lekérhetőek a hivatalos kárpótlási jegy információk. Ehhez nyilván 25 éve senki nem nyúlt, de ott van.

• #16 hcl titán Vision #15

  Új Válasz 2021-12-13 10:09:57 #16

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  hcl

  titán

  LOGOUT blog (1)

  válasz Vision #15 üzenetére

  Ha meg betörnek a banki rendszerbe, az még több pénz (és ezt a Log4shell-t már tudhatólag kihasználták ). Lehet választani. (2019 óta, ne már.)
  Nem hajlok rá, hogy sajnáljam a bakokat.

• #15 Vision veterán hcl #14

  Új Válasz 2021-12-13 10:06:08 #15

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Vision

  veterán

  válasz hcl #14 üzenetére

  Nem erről van szó. A banki rendszerek jó része egyedi fejlesztés, upgrade esetén a beszállítónak kell hozzá húznia az appot/validálnia kell a helyes működést. Ez idő, pénz.

• #14 hcl titán Vision #13

  Új Válasz 2021-12-13 10:01:37 #14

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  hcl

  titán

  LOGOUT blog (1)

  válasz Vision #13 üzenetére

  Azokkal nincs is olyan nagy gond. De ami kintről elérhető, azt muszáj patchelni, mert ezen kívül is durva hibák lehetnek...

  Voltam szerveradmin, a legtöbb "nem ennyire egszerű" eset adminisztratív nehézség volt (Akár az is, hogy nem aakrják megvenni az újabb verziót, inkább az admint szívatják, hogy oldja meg compliantre azt az outdated cuccot, ami van, de pl. csak bizonyos kernelverzióval megy, stb.)

• #13 Vision veterán hcl #12

  Új Válasz 2021-12-13 09:56:24 #13

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Vision

  veterán

  válasz hcl #12 üzenetére

  Ez nem ennyire egyszerű. Másrészt van számtalan olyan app, ami külső hálóról nem elérhető, ott kevésbé égető az ilyesmi.

• #12 hcl titán floatr #11

  Új Válasz 2021-12-13 09:40:54 #12

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  hcl

  titán

  LOGOUT blog (1)

  válasz floatr #11 üzenetére

  Komolyan, egy olyan lyukas dolgot, mint a Java, olyan rendszerekben, amikben pénzügyeznek, csak a hülye nem updatel. Még nálunk is folyamatosan patchelve vannak a Java-s ERP cuccok...

• #11 floatr veterán hcl #9

  Új Válasz 2021-12-13 09:13:57 #11

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  floatr

  veterán

  válasz hcl #9 üzenetére

  Ezernyi olyan cég van, aki java 8-ban ragadt, főleg pénzügyi szoftverekkel bankok. Jó eséllyel a runtime-ot sem frissítik

• #10 Vision veterán

  Új Válasz 2021-12-13 08:51:26 #10

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Vision

  veterán

  Nálunk is összeszaladt az egész cég emiatt, főnök hívott is szombaton, hogy mi a helyzet. Szerencsére minket kevésbé érint, csak függőségként van behúzva a log4j, nincs aktív használatban.

• #9 hcl titán strogov #7

  Új Válasz 2021-12-13 08:44:42 #9

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  hcl

  titán

  LOGOUT blog (1)

  válasz strogov #7 üzenetére

  Mondjuk aki 2019 óta nem frissítette...

• #8 #68216320 törölt tag

  Új Válasz 2021-12-13 08:40:21 #8

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  #68216320

  törölt tag

  Jól gondolom, hogy elég lenne átírnom a Maven (pom.xml) verziót erre és csak build kell megint és védve vagyok? Vagy ennél összetettebb a probléma?

• #7 strogov senior tag hcl #6

  Új Válasz 2021-12-13 08:19:15 #7

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  strogov

  senior tag

  válasz hcl #6 üzenetére

  Azt jelenti, hogy nincs lookup, így a megadott verziók (és újabbak) nem támadhatók ezzel a módszerrel.
  Ott van egy curl tesztelni, és akkor kiderül úgyis. Aki meg nem tud egy curl-t lefuttatni annak mindegy.

• #6 hcl titán hallador #1

  Új Válasz 2021-12-12 21:58:07 #6

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  hcl

  titán

  LOGOUT blog (1)

  válasz hallador #1 üzenetére

  Szerintem 3rd party alatt azt értették a Crowdstrike hírben, hogy olyan appok, amikbe be van építve.
  BTW egy patchet egy kisebb szolgáltató is fel tud tenni, ha csak annyi.

  Amit még nem értek, a CVE-ben
  "Both of the most popular Java implementations, Oracle JDK and OpenJDK, have shipped with a default setting that should prevent exploitation since 2019; the variable com.sun.jndi.rmi.object.trustURLCodebase is set to false by default, disallowing access to remote resources. "
  Akkor ez most mi...

• #5 KAMI911 senior tag Fecogame #4

  Új Válasz 2021-12-12 21:07:13 #5

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  KAMI911

  senior tag

  válasz Fecogame #4 üzenetére

  Van lehetőség némi workaroundra, itt összeszedtem őket :

  [link]

• #4 Fecogame veterán

  Új Válasz 2021-12-12 19:20:06 #4

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Fecogame

  veterán

  Ha valamiért nem frissíthető a Log4j az adott rendszeren (mert mondjuk a repo-ban nem elérhető a frissebb verzió, stb.), akkor van valami beállítás, amivel ez a sebezhetőség kivédhető?

• #3 gabor7th addikt hallador #1

  Új Válasz 2021-12-12 14:45:35 #3

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  gabor7th

  addikt

  válasz hallador #1 üzenetére

  Igen, meg el van felejtve, hogy a sebezhetőséget mások már ismerhették és akkor ilyenkor a felhő egy svédasztal a hackereknek.

• #2 tomazin veterán

  Új Válasz 2021-12-12 13:34:29 #2

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  tomazin

  veterán

  Hat kivancsi leszek, hogy eleg lesz-e a maven/gradleben verziot emelni es kesz a dolog. Kosz a hirt!

• #1 hallador addikt

  Új Válasz 2021-12-12 11:44:11 #1

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  hallador

  addikt

  Na igen a kisebbek most eléggé bajban lehetnek, na de nagy eséllyel őket nem is úgy támadják, ahogy az Amazon, Apple rendszereit. reméljük a legjobbakat.

Új hozzászólás Aktív témák