Security-all

Helló

Az igényeim, hogy szerte a világban legyen végpontja, működjön Linux és Windows 11 alól is a Vpn kliens, ezért az Openvpn vagy Wireguard klienst szeretnék.

Eddig az Ipvanish Vpnnel van tapasztalatom, hogy működik. Lejárt és gondolkozom, hogy melyik legyen.

A cél az, hogy több országból tudjak elérni egy adott weboldalt, főként web böngészőből, főként Linux alól.

A többi Vpn szolgáltató mivel tud többet, mint az Ipvarnish?

Mi az, ami szerinted fontos egy Vpn szolgáltató választásánál? Melyik szolgáltató emelkedik ki valami jóban és miért?

Ingyenes Vpn szolgáltatásoknak, mint a böngészőbe épített (Opera) Vpn, mi a hátrányuk? Ezeket lehet vagy érdemes kombinálni más Vpn szolgáltatással?

Nyilván a legjobb az lenne, ha olyan ip címem lenne, amiről nem egyértelmű, hogy Vpn. Azonban mivel több országból akarom használni, nem tűnik költséghatékonynak, hogy több országban bérelnék egy kis virtuális szervert amin keresztül netezek. Az sem tűnik jó ötletnek, hogy random netes proxy listákból ki tudja milyen gépeken át használom. Elfogadható az is, ha látszik, hogy vpnt használok, hacsak nincs valami vpn árban lévő más megoldás.

Mire képesek a hackerek :), Hacker eszközök és 5 dolog amivel védheted magad, 18 perces videó

Ryan Montgomery

https://youtu.be/9x7LKoutoVE?si=QHB5TlUPAm_J0DQX

Ryan oldala:

https://pentester.com/

Sziasztok!

Van egy működő kereskedelmi SIEM rendszerünk, ami a hálózati forgalmat figyeli jelenleg, viszont nem gyűjti a kliensekről a naplókat. E mellé van egy vírusvédelmi rendszerünk is. E mellé szerintetek van értelme még egy SIEM rendszert (ez a Wazuh lenne) beüzemelni a felhasználók gépeit terhelni az agent-ével? Több felé próbáltam utána nézni, én nem találtam meggyőző érvet (inkább a mostani SIEM-nek kellene tárhelyet bővíteni és bővíteni a tárolandó adatok körét). Olyat is láttam, hogy egy log gyűjtő szerver összeszedi a naplókat és tárolja (NXlog-gal), és ezt elemzi a SIEM. Várom a javaslatokat!

Sziasztok!

ÉLŐ DIGITÁLIS -RABLÓ VADÁSZAT!!!

VADÁSSZUNK ÉLŐBEN MBH BANK feLtörést végző bűnelkövetőket! 

Tegnap  reggel újabb aktív, csaló MBH Bankos phishing oldalt sikerült fellelni az  (mhb-netbank.com).

A kiberbűnözők ugyanazt a trükköt játsszák el újra meg újra:

magyar felület, MBH logó, Google Trust Services tanúsítvány (hivatalos, “biztonságos” lakat),

profi kinézet – és már viszik is a gyanútlan ügyfelek adatait.

Ja és hát a bevált Cloudflare infrastruktúra! 

IT-s, sysadmin, security-s, fehérkalapos!

Videó a "bátor" mhb-netbank.com oldalról ITT.

Te hogyan vadásznál le egy ilyen csaló oldalt?

– Mit használsz domain huntingra, CT log, abuse, blacklist, crawling, AI vagy más módszer?

– Van valami home-made scripted, vagy “hacker-tipp”, hogy felismerd, hogy újabb MBH-s kamudomain indult?

– Működik valami közösségi report, vagy mindenki csak magában szívja a fogát?

Ja és hiába jerlentettük le mindenhol, a regisztrátornál, a Cloudflarenél, meg hiába hivatkoztunk arra is, hogy EU védjegye van az MBH BANk-nak.  Itt most ez, sermmit sem ért! 

KAPJUK EL AZ ELKÖVETŐKET, GYŰJTSÜNK  ADATOT RÓLUK:ÉLŐBEN! 

Közösségi online edukáció, tapasztalat közmegosztás meg itt!

Sziasztok!

Belefutottam egy számomra teljes mértékben érthetetlen korlátozásba az OTP-nél: egy telefonszámhoz nem enged több internetbank regisztrációt.
Történt, hogy a napokban nyitottam egy OTP Junior számlát a fiam számára úgy, hogy minden számlánk az OTP-nél van. Az ügyintéző beazonosított engem, látta is a szerződésünket, a számlát sikeresen meg is nyitotta, majd az internetbank szerződés létrehozásához elkért egy telefonszámot. Egy szóval sem jelezte, hogy nem lehet olyan szám, amihez van már internetbank. Mivel a gyereknek nincs telefonja, így a sajátomat adtam meg.
Ezek után este, mikor csináltuk volna a regisztrációt, jelezte a rendszer, hogy egy számhoz nem lehet több regisztrációt rendelni...
 

Mi értelme van ennek a korlátnak? Milyen biztonsági problémát okozhat, ha megengednék? Más bank is korlátozza ezt?

Most lehet majd újra besétálni személyesen, hogy telefonszámot változtassunk, feltéve, hogy lesz a gyereknek olyanja....

Gábor

Ma is sikerült egy újabb, adathalász MBH BANK oldal lekapcsolását elindítanunk, de kb. annyit ért, mint vödörrel vizet hordani a sivatagba.

A “mhb-netbank.com” domain ügyében hajnalban intézkedtünk, de közben már újabb és újabb másolatok születnek, ugyanazzal a dizájnnal, logóval, csak más végződéssel.

Természetesen a támadók most is Google Trust Services által kiadott SSL-lel csapják be az embereket, és minden biztonsági illúzió adott: zöld lakat, magyar felület, banki logó, minden.

A magyar banki ügyfelek közben naponta adataikat, pénzüket veszítik.

A kamu MBH BANK-i link itt érhető el: https://www.mhb-netbank.com/eib_ib_59/loginpage.hu.html/verification/card  ( a linkben az 5-öst cseréld S-re és láthatod) 
 

Ti hogyan vadásznátok le a csaló MBH BANK oldalakat az Internetről?

– Automata domain-felderítés?
– WHOIS és Certificate Transparency monitorozás?
– Abuse spammelés?
– AI/ML szűrés, crawler, valami home-made vagy létező tool?
– Feketelista, Google/SafeBrowsing, bankszektor közös fellépés?
– Vagy teljesen reménytelen, amíg a Google/Cloudflare és a “domain farmok” adják hozzá az infrastruktúrát?

Osszátok meg a tapasztalatot, trükköt, vagy akár azt, hogyan NEM lehet ezt hatékonyan megoldani.

Ja, és nem, a banki ügyféltájékoztató nem elég. :) 

Update:

Aki kíváncsi, hogyan néz ki egy “tökéletes” csaló oldal annak a kamu MBH BANK-i link itt érhető el: https://www.mhb-netbank.com/eib_ib_59/loginpage.hu.html/verification/card  ( a linkben az 5-öst cseréld S-re és láthatod) 
– MBH logó, magyar szöveg, valid Google SSL, minden browserben zöld lakat.
– Magyar ügyfelek százai verhetik a fejüket a falba, mire rájönnek.

Forrás, cikk, screenshot is van nálam, ha kell – keresd privátban.

Ti hogyan oldanátok meg ezt a küzdelmet, hogy ne csak tűzoltás legyen, hanem rendszerszintű megelőzés?
 

Trollokat, okosokat, laikusokat és paranoiásokat is várok – ebből talán valami közösségi know-how is kijön…

Ez az mbhbank.NU hamis mbhbank.hu oldalba ágyazott script amit a bűnelkövetők használtak és mivel van ahol ez "betárolódott" mi meg ráleltünk, hát bizony jó lenne ha most kiderülne,  mit TUD a magyar virtus! 

De mire is gondolunk? 

A megadott JavaScript fájlok valóban erősen obfuszkált (eltorzított) Cloudflare challenge scriptek, amelyeket bűnelkövetők egy hamis MBH Bank oldalon használtak.

Íme a NAGY KÉRDÉS:  mire szolgáltak ezek a scriptek? 

https://web.archive.org/web/*/http://mbhbank.nu/*

az 1-es  file linkje .JS: https://web.archive.org/web/20250407075052/https://mbhbank.nu/cdn-cgi/c…
a 2.es file linkje .JS: https://web.archive.org/web/20250401124609/https://mbhbank.nu/cdn-cgi/c…
 

..MERT A WEBARCHIVE INTERNET NEM FELEJT!

Köszönjük előre is: honpolgár társaink és a bűnüldözés is biztosan hálás lesz érte!

Szerintünk, lesz itt olyan aki a dicsőségért és akár a szakmai figyelemért IS képes lesz élenjárni szkami tudásával! 

Talán ez a helyzet lehet jó példája annak, hogy a magyar ember OKOS és KITARTÓ!

(igen, lesz aki anyázik, leszól, beszól, meg a jó ég tudja mi... de hát ez van, ez a HUP. Aki tud segíteni, az segít, aki csak trollkodni akar, az úgyis megteszi.)

https://localmess.github.io

A cikk nagyobb részét igazából nem értem (lehet, hogy át kéne párszor olvasni), de a lényeg, hogy a Meta illetve a Yandex használ egy olyan cookie-based megoldást, amellyel a felhasználó böngészését akkor is meg tudja figyelni, ha az incognito módot használ. Elég hozzá, ha a Facebook vagy a Yandex alkalmazás fut a mobilján a háttérben. Cookie törlés nem segít.

Ha jól veszem ki, a böngészőt ráveszi, hogy localhost socketen át kommunikáljon az alkalmazás adott portjaival, és azon keresztül küldi az adatokat.

Androidon működik (ténylegesen), iOS-t és desktop rendszereket még nem nézték át alaposan.

Sziasztok,

Naponta több tízmillióan kattintunk a "Bejelentkezés Google-fiókkal" gombra, szinte már reflexből, feltételezve, hogy a google.com domain egyet jelent a kikezdhetetlen biztonsággal.

De mi van akkor, ha pont ez a vak bizalom a támadók legújabb és leghatékonyabb fegyvere? A linkelt cikk egy olyan, a valóságban is megfigyelt támadási láncolatot boncolgat, ahol a kiberbűnözők nem egy obskúrus, gyanús domainről, hanem egyenesen a Google egyik hivatalos OAuth végpontjáról (accounts.google.com) töltöttek be rosszindulatú kódot a felhasználók böngészőjébe.  

A módszer pofonegyszerű és épp ezért zseniális: egy JSONP-stílusú callback paramétert fegyverként használva kerülték meg a legtöbb biztonsági szűrőt és a domain-alapú CSP-ket. A végeredmény? Egy rejtett, perzisztens WebSocket csatorna, ami lényegében egy parancs- és vezérlő (C2) szerverként funkcionált a gyanútlan áldozat böngészőjében, készen arra, hogy valós időben lopjon el például bankkártyaadatokat a fizetési oldalakról.  

Ez felvet néhány kényelmetlen kérdést a fejlesztői gyakorlatainkkal kapcsolatban:

• Elég ma már egy script-src 'self' *.google.com; egy CSP-ben, vagy ezzel csak hamis biztonságérzetet adunk magunknak?
• Hol húzódik a határ a Google (vagy bármelyik nagy szolgáltató) felelőssége és a webfejlesztő gondossága között az ilyen, legitim szolgáltatásokat láncba fűző támadásoknál?
• A "living off the land" támadások korában a reputáció-alapú védelem halott? Bízhatunk-e még egyáltalán a domain nevekben?  

A teljes technikai elemzést és a lehetséges védekezési stratégiákat (a szigorú CSP-től a Trusted Types-ig) ebben az elemző cikkben találjátok: https://euroastra.hu/a-megbizhatosag-fegyvere-a-google-oauth-vagy-egy-uj-felhasznalok-elleni-tamadas-lehetosege-tanulmany-a-google-oauthrol/

A TÉMA felvetés  célja, hogy NE egymást "kavicsozva" és "leszólva" hanem szakmailag is a témáról beszéljünk. Az MBH Bank és Google online csalás ügy árnyékában ez a téma SOS aktuálissá érett! 

Iphone bluetooth hack - rövid érdekes videó

https://www.youtube.com/shorts/KHsmz7tnhHk