Security-all

A PuTTY egy hibás metódust használt az elliptikus ív kulcsgeneráláshoz, ami során kikerültek a privát kulcsok.

https://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/vuln-p521-b…

Javítás: frissíteni 0.81-re, és minden olyan kulcs cseréje, ami a korábbi verzióval használva volt.

Bővebben: a PuTTY a NIST P521-et használta (ecdsa-sha2-nistp521), amiben sérülékenységet fedeztek fel (CVE-2024-31497). A javított verzió nem használja már ezt a konkrét metódust ezzel a konkrét kulcsmérettel. Öröm az ürömben, hogy más kulcsméretek úgy látszik nem voltak érintettek, illetve akkor sincs baj, ha a szerver oldali SSH-ban le volt tiltva a NIST P521, ezért a handshake-nél más metódust választott a PuTTY. Az nem egészen világos számomra, hogy lehet kihasználni ezt (feltéve, hogy a szerver is ugyanaz a security domain), de jobb a biztonság.

Kedves Ügyfelünk!

Ezúton szeretnénk tájékoztatni az SSL tanúsítványához kapcsolódó fontos változásról!

A vonatkozó iparági szabványok változására tekintettel az SSL tanúsítványok esetében a UserNotice mező használata a nem engedélyezett.

A szabványváltozásnak történő megfelelés miatt a 2023. szeptember 15. napján és ezt követően kiadott SSL tanúsítványok esetében a jelenlegit lecserélendő, új, a UserNotice mezőt már nem tartalmazó tanúsítvány kerül kibocsátásra, ütemezetten és tervezetten 5 napon belül. Ez a jelenlegi SSL tanúsítványának megújítását jelenti a gyakorlatban.

Az új kiadáshoz tartozó tömörített és jelszóval ellátott tanúsítványt, külön emailben küldjük meg az Ön részére.

Önnek annyit kell tennie, hogy a megküldött új tanúsítványt lecseréli rendszereiben.

Fontos, hogy erre egy megadott időablakban van lehetőség!

Időablak: új tanúsítvány érvényességének kezdete és 2024.04.09. 09:59 óra (közép-európai idő) között.

Új tanúsítvány érvényességének kezdete: a kiadást követő napon, az eredeti tanúsítvány kiadásának (óra/perc) idejétől kezdődik.

Új tanúsítvány érvényességének vége: megegyezik az eredeti tanúsítvány érvényességi idejének végével.

Kérjük tehát, hogy mindenképpen cserélje le a meglévő tanúsítványt az új tanúsítványra az új tanúsítványban szereplő érvényességi idő megkezdését követően, de legkésőbb 2024.04.09-e 09:59 óráig (közép-európai idő szerint).

A cseréhez a tanúsítványmegújítás technikai lépéseit kell figyelembe vennie. Az alábbi linkre kattintva érheti el szerverleírásainkat: https://netlock.hu/termektamogatas/. (Kérjük, görgessen az “Eszköz és szerver beállítások” sorig.)

Az új tanúsítvány kiadását követően az eredeti tanúsítvány legkésőbb 2024.04.09. napján közép-európai idő szerint 09:59 órakor visszavonásra kerül, amelyről külön értesítést már nem fogunk küldeni.

Tájékoztatjuk, hogy az új tanúsítvány díjmentesen kerül kiállításra.

Amennyiben a fentiekkel kapcsolatban kérdése merülne fel keressen bennünket bizalommal az alábbi elérhetőségeken.

Együttműködésételőre is megköszönjük és az okozott kellemetlenségért elnézést kérünk.

Üdvözlettel:

NETLOCK

https://www.openwall.com/lists/oss-security/2024/03/29/4

Érdekesség: sem a hivatalos forrásban, sem a github forrás mirrorban nem található meg a backdoor, csak a github release-ben.
Minden olyan distro érintett, ami ez utóbbit használja (például a debian csomag is ebből generálódik).

Ha jól emlékszem, akkor pont ilyenbe bukott bele a sourceforge, ezek szerint ugyanez a sors vár a github-ra? Sourceforge esetében a mirror volt a ludas, kíváncsi vagyok, a github-on hogy kerülhetett bele.

Sziasztok!

Ismerős a káhánál bankol. 1 hete letiltotta a bank a hozzáférését a netbankhoz, telefonos alkalmazáshoz mert valaki egy új telefonon keresztül akart hozzáférni az ő számlájához (ismerősnek almás telefonja van, az új eszköz pedig androidos). Elvileg ennél a banknál van egy azonosító és egy jelszó felírva valami kis kártyára és azzal kell regisztrálni új eszközt (lehet nem tökéletes minden infóm). Ezek az adatok valahol mélyen el vannak rejtve egy széfben, nem fért hozzá senki. Az telebankos ügyintéző szerint ukrán ip-ről jött a próbálkozás és több felhasználót is érint a probléma. Ugyanarról az ipről több azonosítóhoz próbáltak hozzáférni. A bank tiltotta a számlákhoz való hozzáférést.

Az ismerős nem adta ki a telepítési információit, nem hívta senki, hogy segítene neki mert baj van a számlájával, nem akart semmit fb-on eladni. Szóval elvileg nem hibázott ami miatt kikerülhetett bármilyen szenzitív infó. 

Hogyan lehet megelőzni az ilyen helyzeteket?

Az ismerős hibázott vagy sem ?

Hogyan lehet, hogy mégis megvolt minden infó amivel hozzáférhetnek a számlához ?

Előre is köszönöm a válaszokat.

Sziasztok!

Egy béna kérdésem lenne. Ha egy alkalmazásban (Zimbra levelezés) bekapcsolom a 2fa-t, akkor a kliensekhez (thunderbird, stb.) kell generálnom egy passcode-ot. Ez egy 16 karakteres kód, amit az adott appban (és esetleg másikban is) használhatok jelszó helyett. Ez a passcode mennyivel komolyabb védelem annál, minthogy előírnám a usereknek,hogy eleve minimum 16 karakteres jelszót használjanak? Van így bármi értelme a 2fa-val szenvedni?

Hello,

Adott egy Apache + Modsecurity 2 kombó. Teszi is a dolgát úgy ahogy kell, viszont jött egy olyan ügyfél oldali igény, hogy szeretne egy saját fejlesztésű HTML editort használni, ami mentésnél mindig modsec szabályba ütközik. Ennek nyilván így is kell lennie, mivel a modsec pont arra van, hogy az efféle huncutságokat megfogja. Az (nem) megoldás, hogy kikapcsolom a szóban forgó szabályokat a mappára/oldalra, de ezt hogy lehet szebben megcsinálni, hogy ne a szabályrendszert csorbítsam?

Előre is köszönöm

Na, ez az igazán durva! Paranoiások ne olvassák tovább! Én szóltam.

https://kitchener.ctvnews.ca/facial-recognition-error-message-on-vendin…

Earlier this month, a student noticed an error message on one of the machines in the Modern Languages building. It appeared to indicate there was a problem with a facial recognition application.
"We wouldn't have known if it weren't for the application error. There's no warning here,"

A képernyőkép itt megcsodálható: https://kitchener.ctvnews.ca/content/dam/ctvnews/en/images/2024/2/22/ve…

Hat, ujfent csak gratulalni tudok a donteshozoknak, meg a felkeszult IT csapatnak is.

https://sverigesradio.se/artikel/inmates-able-to-access-internet-in-the…

Sziasztok,

Másodszora futok bele hogy rendelek nagy magyar webshop-ról ahol napi több ezres+ rendelés lehet, és a bankkártya fizetési rész nem egy jól ismert bankon keresztül megy külön ablakban, hanem ők kérik be a
 * bankkártya számot
 * lejárati időt
 * CVC kódot

Az egyiknél konkrétan láttam hogy console-ból titkosítatlanul küldik a bankkártya adataimat a saját szervereik felé, de az 10 éve volt, azóta lehet más rendszerük van. Itt napi 10.000 rendelés lehet.
A másiknál csak gyanakszom hogy ugyanez lehet mert egyszerűen bekérték a bankkártya adataim és majd valamikor feldolgozzák a rendelést. Itt is napi több ezres rendelés lehet.

Honnan tudhatom hogy az ottani rendszergazda/operátor nem filtereli ki a bankkártya adataim egy txt fájlba?

Van erre valami szabályozás hogy ilyet nem lehetne?

Nem érzem biztonságban a kártyámat és a pénzemet.
 * A CVC kód azért van hogy csak én tudjak róla.
 * Honnan tudjam hogy egyszer csak kapok egy sms-t Ön Görögrszágban fizetett 50.000 Ft-t? És akkor nekem kell vele foglalkozni ügyintézni.

webkártyát használok, limittel, de nem ez a megoldás
 

Megoldható-e ,hogy egyszerű és könnyen megjegyezhető jelszavakat használjunk, és mégis megmaradjon a biztonság?

https://sign-el-soft.hu/keygen.html

-------------------------------- Kiegészítés 24.02.09 16:15

Itt nem egy random jelszógenerátorról van szó!

A felhasználó beállítja a saját szabályát, és annak alapján egy algoritmus egy rövid és ezért könnyen megjegyezhető bemenetre, a kívánt hosszúságú és formátumú kimenő jelszót állít elő.

Ugyanarra a bemenetre legközelebb is ugyanazt a választ fogja adni, másik bemenetre egy másikat.

Ha a szabály más, akkor mások a kimenő jelszavak.