Sikeres IT támadások okainak feltárása - megelőzése

Fórumok

Sziasztok!

Olyan összesítő statisztikát, leíró blogot keresek, ahol a különféle sikeres támadások okait feltárták és őszintén leírták. Mert ebből tanulhatna a szakma.

Minden hétre, akár napra is jut egy cég IT rendszerébe történő betörés vagy crypto vírussal való lenullázás.

Jó volna egy ok- okozat - megelőzés gondolatmenetet olvasni ezekről.

Ha ilyenből híján vagyunk, akár ezen topikban is összegyűjthetünk párat. Itt biztos hígabb lesz, mint egy blog cikk, de mindannyian tanulhatunk belőle.

Köszönön!

Hozzászólások

Mert ebből tanulhatna a szakma.

Ezen felröhögtem :D

Fedora 42, Thinkpad x280

En a megelozes, proaktivitas hive vagyok, Tokmindegy, hogy nem mi vagyunk a celcsoport. Amennyire csak tudunk, elokeszulunk minden eshetosegre. Bank vagyunk amugy. Szerintem egy rendszermernoknek ez a feladata, felkeszules a worst scenariora, illetve azt megelozni, hogy az bekovetkezhessen.Proaktivitas. Ha ez nem igy lenne, akkor a munkakorom felesleges lenne.

I don't run often, but when I do, I run as administrator.

Az egyik IT biztonságot oktató tanáromtól hallottam (akit itt szinte mindenki ismer), hogy az IT biztonságot a használhatatlanságig lehet fokozni és az a legbiztonságosabb amit nem használnak!

Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

kurvára nem érdekli a közép-felsővezetést, ha már aláírták a szerződést, erre hangosan okoskodik vmi hülyegyerek a budapesti szekuriti tímben, hogy ez az izé amire most basztak el 100millió EUR/USD/GBP-t, nem szekjur és ki kellene kapcsolni. Hiába igazad van. Zoom-ot is megvették sok helyen, hiába ugatott a sok hülye security engineer. Mondjuk az szokott lenni a döntési lánc, hogy először megveszik, aztán basszák oda a security team elé, hogy na ezt fogjátok enni, tetszik nem tetszik, pont. Akinek nem tetszik, annak arra van az ajtó. A mindig bólogató seggnyaló security team lead-ek meg akik nem mernek ellentmondani, na azok maradhatnak, és munkaköri feladatuk a szopás ezekkel a szarokkal. Amíg kussolsz, bólogatsz és egyetértesz, addig maradhatsz egy multinál alkalmazva. Ha (hiába jogosan) kötekedsz meg rámutatsz bajokra, azt nem szereti a közvetlen főnököd, annak a főnöke sem, feljebb meg nem is jut a hangod. Ha meg nagyon feljebb akarsz panaszkodni, hamar kibasznak. Multik csak a pofabe, és nyeljed a mérget 10-20 évig alkalmazottat szeretik. Aki aztán gyomorrákkal hamar megdöglik 50 évesen.

Security-vel szabadúszó beugró penteszterkedőknek v. 0day keresgélőknek jó lenni, nem kibaszott multis főállású alkalmazottnak, a multis lét minden hátrányát elviselve.

Kicsit megértem azért a középvezetést. 

Jön mondjuk egy COVID, és a kormány bejelenti, hogy mindenkinek takarodó van haza. Neked meg kell oldani, hogy a jobbágyok tudjanak továbbra is dolgozni, mindezt véges zsetonból véges idő alatt. (Igen, értem, az előrelátó cégek már évekkel korábban ráálltak a HO-ra, tökmindegy.)

Szóval ja, akkor melyik legyen? Zoom? Hát az nem secure. Teams? Ja, hát ahhoz le kéne porolni az O365 migrációt, az MS Projectben készült terv valahol egy SMB1-es network share-en vannak. 

Ha ebben a helyzetben az IT security csapat konkrét kockázatok helyett (a kockázatok várható értékével!!!) olyanokat mond, hogy "nem biztonságos, mert ha valaki megtippeli a call ID-t [10 karakter] és a jelszót [6 karakter], akkor be tud jönni faszt villantani az értekezletre", akkor azért én is felhúznám magam. És volt ilyen, bőven volt ilyen a COVID elején. Esetünkben átálltak valami másra, mert a Zoom nem secure, tele van szatírral, az új platformon ugyanúgy lófaszt sem konfiguráltak be, és hát ott is belépkedtek a mutogatós bácsik.

Az egyik hülyének sem jutott eszébe, hogy nem a 10+6 karaktert tippelik meg helyesen egyszerre többen, hanem a vicces kedvű kolléga kirakta 4chanre a meeting ID-t. Céges account meg ugye nem követeltek meg a belépéshez, mert hát minek olyasmivel foglalkozni, hogy access control.

Senki sem adja ki önként a szegénységi bizonyítványát. Max TED-en hallhatsz anonimizált történeteket.

1904.04.08.
RIP Jákub.
neut @

Igen, kevesen merik bevállalni. Csak jó volna látni hol volt a gyenge láncszem, mert az erőforrásokat érdemes oda összpontosítani.

Feltételezem, többen olyan irányba javítják a biztonságot, ahonnan nem is jön fenyegetettség, aztán elcsúsznak egy banánhéjon (pl. emberi mulasztás).

Én a Hack és Lángos podcastet hallgatom ebben a témában látókörtágítás gyanánt.

Óhát roppant egyszerű ez, és túlgondolod. Az esetek többségében a nemfrissülő, úgyhagyott gépekhez, rendszerekhez férnek hozzá. Ez lehet egy desktop amire néha jön egy levél, amiből egy malware volt, vagy egy VPS valami eldugott helyen, miközben az hozzáfér valamihez. Teljesen banális a dolgok nagy része. A kevésbé banális, ha kapnak egy fertőzött pendrive-on valamit, de ehhez is kell az előző elhanyagoltság (feltéve, hogy ne testreszabott cuccot kaptak, mert akkor valszin mind1).

Egyéb más topikokban ezekről már többen írtunk, különösebb újdonság nem lesz.

Ahol konkrétan az adott szervezetet célozták, az pedig nagyon nehezen védhető, csak a már ismert fizikai biztonság, dolgozói megfelelőség, mindenféle policy-k alkalmazása ad valamilyen szintű védőhálót. Ezt indulhat úgy, hogy egy futárjellegű bedug egy pendrive-ot valahova, vagy egy szabad hálózati aljzatba valamit, odáig, hogy kvázi beépülnek valahogy a dolgozók közé. Jól látható, hogy az első ellen viszonylag könnyű védekezni, a második ellen azért már szervezeti belső elhárítás kellene.

Előszedném a kedvencemet, a dolgozók képzését a social engineering támadások ellen (phising on steroids jellegűek), meg minden hasonlóra felhívni a figyelmet, hogy észnél kell lenni.

A phishing-re csak 1 árnyalt ellenpélda: egy multiban dolgozol, IT területen. Max a közvetlen csapatod által felügyelt v. üzemeltetett rendszerekre van bármi rálátásod. A többi rendszert más kis csapatok örzik foggal körömmel, ki nem adva az irányítást a kezükből. Szószerint hetente, de legalábbis havonta jön be valami új 3rd party szar: pl. szabadságkezelést jellemzően félévente-évente valami más kontár külső kft szarjába outsource-olják. Vagy a kafeteria választós weboldalt. Vagy az utazásjóváhagyós szart. Vagy az utazáselszamolásos szart. A mikroszoft szarságai hányják magukból a hírleveleket, whatsnew, daily productivity newsletter shit. Valamint jönnek a mindenféle maintenance üzenetek olyan szarokról amikről életedben nem is hallottál, Aztán hirtelen a kékégből valaki ismeretlen hozzáadott valami ismeretlen nevű szarnak a valami ismeretlen szar funkciójához mert elvileg valami nyilvántartás szerint neked is baszni kellene valamit azzal az ismeretlen szarral mától kezdve. Ezt szorozd meg 10-el v. 100-al ízlés szerint, és utána mondd el nekem szúrópróba szerűen egy tetszőleges ilyen témájú ismeretlen cégtől jövő levélről, hogy abban most téged pissingelni akarnak, vagy nem? Emberileg lehetetlenség h. a globalice teljes multiban folyó összes szarságról a legutolsó szintű biorobot dolgozót (általában te és a veled egy szinten levő többi alkalmazott) megfelelően tájékoztatni.

Ezekután nem csoda ha bárki be tud nyelni egy kicsit is jól megcsinált phishing-es csalit.

Nem tudsz mit csinálni a multis problémával, azt a multi mint szervezet kell kezelje. Ha nem kezelik, akkor ez van, ha meg kezelik, akkor jön a szigor, és mindenki háborog.

Abban biztos vagyok, hogy érdemben csökkenthető a veszély, és a kedves felhasználók (akármekkora ájti guru, valaminek ő is a felhasználója, lásd xy millió productivity szuperrendszer) figyelmének erre irányítása fontos. Miért kéne minden folyamatról tudni? Arról viszont kéne tudni, hogy amivel neki van dolga, azoknál mi a normális, és mi a phising jellegű, és ha máshonnan kap emailt, akkor meg gyanakodni inkább, mint vadul klikkelni. Ha meg fals pozitívat jelent be, akkor a szupermulti lesz szives megköszönni, és átnézni a folyamatokat. Erre remek menedzseri plusz productivityt lehet kitűzni, KPI!!!! :)

Ahogy már a másik topikban jeleztem képtelenség kiszűrni minden phising próbát, pláne olyat, ami esetleg nagyjából a multira van szabva, vagy egy valamilyen elterjedt rendszerre. (Tehát hogy világos legyen, mindet képtelenség kiszűrni, ha a 90-95%-ot kiszűrik, akkor még komoly darabszámú átjutó lehet, pedig az egy igen jó arány.)

"A Kiberbiztonsági Főcsoport ezúton emlékezteti a kollégákat, hogy figyeljenek az ismeretlen feladótól, nemlétező szervezeti egységektől érkező levelekre. Egyben tájékozatjuk a kollégákat, hogy hétfőtől a gazdasági igazgatóhelyettes közvetlen felügyelete alatt Kiberfőbiztonsági Alosztály néven folytatjuk a munkát."

Szerkesztve: 2022. 10. 26., sze – 13:31

A 2017-es Maersk Wannacry/Notpetya incidens elég részletesen leírták:

The Untold Story of NotPetya, the Most Devastating Cyberattack in History | WIRED

https://www.youtube.com/watch?v=wQ8HIjkEe9o

https://www.linkedin.com/pulse/notpetya-happy-5th-birthday-bob-will-owen

Maersk, me & Notpetya - Gavin Ashton (gvnshtn.com)

 

Persze sok lesz benne a bullshit, nyomják a nagy "corporate values" faszságokat. Mikor szimplán csak basztak peccselni időben, és a világ leggazdagabb szállítmányozó cége sajnált 1 kis aprópénzt értelmes szekuritire, csak miután majdnem leradírozták őket a térképről. Cserébe több ezer embert (Maersk munkavállalókat, főleg az IT-t, meg mikroszoft és Deloitte&tsai külsőst csilliárdokért berángattak) dolgoztattak állat módjára hónapokig, amíg a kuplerájt nagyjából összetákolták működőre. De nyilván ezeket nem lehet megírni publikusan. Szóval a tündérmese részét nem szabad elhinni, a varázslatos fordulatok gyanúsan ferdítések és hozzáköltések (kb. mint egy Walter Izsákson könyvben, az a faszi bazdmeg a nagy IT-mesemondó), a hihető tényeket meg az ötleteket esetleg meg lehet fogadni.

Látod mondtam, hogy elmaradó javításokból van a baj, nem kell semmi izgalmas szuperszolúció a l33thaxoroktól. A helyzet, hogy globál fenékvédési üzemmód van, amint probléma lesz. Egyrészt ha esetleg valami vezető gépe, tevékenysége (felszippantot egy malware, vagy phising emailt) okozta, az ugye nem derülhet ki, meg az sem derülhet ki, hogy a csilliódolláros szupermegatűzfalmegoldás (felhő!!!!) csak bután nézett maga elé amikor átjött az email, vagy amikor az IPS jellegű proxy nem fogta meg az amúgy szemmel láthatóan gyanús linket, hiszen feketelistával, meg szabályokkal dolgozik. Az szintén nem derülhet ki, hogy az ájti esetleg lusta volt, vagy inkább vissza volt fogva (hiszen mindíg marhaságokkal bombázzák a szent juzereket, és megy az aknamunka), meg az adott felelős menedzser nem dolgozhat rosszul...

Amit több kisebbnél látok itthon az meg maga a katasztrófa (már mondták, hogy mennyire frusztrált vagyok, roppant meglepő, amikor a falra hányt borsónak több értelme van, mint az ájti alapokat megpróbálni bevezetni). Volt épp nemrég zero backup policyval hasító sokszámjegyes forgalmú cég, Win2008r2-t 2019-re cserélésen hónapok óta gondolkodó (ha windows van, és nincs pénz az új licenszre, akkor wtf-et gondolnak? tényleg ekkora tétel 150k huf egy jól működő cégnél?), meg volt szuperszakértőnek kikiáltott valaki, aki emailre nem hajlandó válaszolni, körben kommunikál, majd megjelenik egy tucatrouterrel (nem-mikrotik).

különféle sikeres támadások okait feltárták és őszintén leírták

Hát az elég naív elképzelés hogy bárki őszintén publikálná.

Az általam ismert esetek 101%-ban kamu volt a kapcsolódó publikáció.

legtöbb esetben még a belső is.

Sőt, én is rosszul láttam.

Nemcsak utána de közben is működhet a nyitottság: https://www.youtube.com/watch?v=C6MDz-AgQuE

Elég nyitottak voltunk amikor velünk történt. A DART így publikálta: https://news.microsoft.com/transform/hackers-hit-norsk-hydro-ransomware…

Bejöttek nagy rendetlenséget csináltak de a végén csak megtalálták a helyüket: https://therecord.media/europol-detains-suspects-behind-lockergoga-mega…

Az eszközük meg ide jutott: https://techcrunch.com/2022/09/19/lockergoga-ransomware-decryption/

Ehhez kell egy kis bátorság. ;-)

Volt pár éve egy blackhat-es előadás, YT-n fent van, hogy az előadó jóember shodan segítségével miket talált neten lógva nyitott http/vnc/rdp portokon lógni. NVR-ek tömegével, de volt közte mindenféle hőerőmű meg biomassza erőmű vezérlő (windows GUI-s) számítógépe, vagy valami acélkohóban a felfűtést végző rendszeré. Mondta, ha az igaz lett volna, és kárt akar okozni, százak halhattak volna meg és milliárd dolláros károkat tudott volna okozni esélyesen.

Hozzánk úgy jöttek be, hogy egy ügyfél e-mail szerverét megnyomták, majd valós e-mailbe valós linket (feltételezem az ügyfél küldte) megszerekesztették. A dolgozónk rákattintott megnyílt a weboldal amire számított de közben települt egy trójai amit akkor a frissen tartott víruskereső nem fogott egy frissen tartott windows 10-en. A támadó mimikatz segítségével és egy cached domain admin jelszóval megvalósÍtotta a "lateral movement" eseményt. A biztonság kedvéért a domain truston keresztül átjutott másik domain-be is. Ezt megnehezítette volna ha van Active Directory Tier modell bevezetve. Ma már ezt így hívják: https://learn.microsoft.com/en-us/security/compass/privileged-access-ac… Óvatosan és lassan dolgozott egyszerre sosem okozott nagy zajt. Egyik tevékenysége sem ütötte meg a SOC ingerküszöbét.  Hónapokkal később kivárta a megfelelő alkalmat. Az új CEO bejelentésének a videóközvetítétsének az idejében terítettette a motyót (Lockergoga + powershell indító script); így a kiugró hálózati forgalmat sem lehetett észrevenni, majd aznap este a domain adminjával minden domain admin és lokál admin jelszót lecserélt és psexec-el elindította a titkosítást oly módon, hogy nemcsak a felhasználói fájlokat hanem komplett rendszereket rendszerfájlostól eltitokosított. Miután domain adminja volt 100%-ra patchelt szerverek és kliensek is elhullottak. Az egész alatt nem számított se tűzfal, se IPS/IDS, se proxy ami szűr se frissre patchelt rendszerek se friss víruskereső motorok semmi (a cucc átment a zscaler-en a symantec-en és a mcafee-n is) A A lockergoga (amit használt) 0 találatot generált a virustotal-on amikkor ránkszabadította. (pedig előtte már használta). Termelési terület csak közvetetten volt érintett a védett kritikus infrastruktúra rész meg egyáltalán nem volt érintett. A cég történetében történtek nagyobb krízisek is: https://www.imdb.com/title/tt3280150/

Ahhoz ilyemiket kellene olvasgatni: https://csrc.nist.gov/publications/detail/sp/800-82/rev-2/final meg képben lenni a Purdue modell-el https://www.automationworld.com/factory/iiot/article/21132891/is-the-pu…. A kritikus infrastruktúra rész annyiban egyszerű mert meg kell felelni a követelményeknek és pont. (ott bizony van air gap is)

Sikeres IT támadást hogyan lehet megelőzni? Hiszen attól lett sikeres, hogy nem előzték meg. Vagyis amit megelőztek, az nem lehetett sikeres.

Gondolom itt a "másoknál sikeres volt - nosza előzzük meg minálunk" a téma.

pl CVE-k napi figyelesevel? csak kerdezem, de mi elsosorban ez alapjan probaljuk megelozni a problemakat.(ok, mas csatornakon keresztul is, de ez nyilvan rendszerspecifikus). Tudom ez sem embertol valo, de en mar csak ilyen fax vagyok, hogy minden reggelem ileyesmikkel indul. Aztan 1-2 napon belul teszteljuk/implementaljuk a megoldast es good to go.

I don't run often, but when I do, I run as administrator.

Ahol ez megvan, ott jó, jellemzően nem ott van a probléma, vagy nem a CVE-k 0day javításának elmaradásával jutnak be. Mára az ájtiszek jóval több, mint frissítések felpakolgatása, és az USB port group policyból tiltása. Teljes szervezetre, minden működésre kiterjedő szemléletet igényel. Ezzel az a legnagyobb probléma, hogy amíg nem vág be atomként a probléma, addig csak lesajnáló tekintetek vannak, és az a mánia, hogy dehát majd az ájti megoldja. Eközben a napi hírek között is van social engineeringgel egybekötött történet, és a felhasználó kiadja az adatait, és nincs 2FA (hiszen az ilyen nehézkes jajjminek), akkor megy a pislogás.

Évekkel ezelőtt volt olyan szolgáltatás, hogy a rendszereidnek megfelelően fizettél elő CVE és egyéb security riasztás-válogatásra, nem tudom, létezik-e még, mindenesetre így egy rakás felesleges olvasgatást meg lehet úszni. Persze ennek megvan azt a veszélye, hogy ha nem tudsz róla, hogy egy adott rendszert vagy alkalmazást elkezdtek használni, akkor nem fogsz rá előfizetni sem. De persze akkor az összes CVE-t is hiába nézed át.

Ráadásul gondolom a policy is kockázatelemzéssel megy, és a publikusak elérhető szerverekre szigorúbb frissítési rend van előírva. Persze ehhez meg a belső hálózatot sem árt jobban szegmentálni.

Most is tudsz ilyenekre feliratkozni pl: NIST-nél. A kérdés, hogy hány ember és mennyi idő van rá.

Például 2017/2018 tájékán kijött, hogy az SMBv1 súlyosan sebezhető, át kell állni legalább v2-re. Sokan nem gondolták, hogy ez sok helyen jelentett hardvercserét - multifunkciós eszközök tömegét kellett lecserélni. Ha bérelt, akkor pedig birkózni kellett a bérbeadóval és/vagy az az eszköz gyártójával, hogy az eszközt cseréljék le nem sebezhetőre. Soha véget nem érő történet volt, sok-sok munkaórát vett el az érdemi munka elől.

Node ez érdemi munka, hogy a biztonsággal foglalkozol. Ha odavernek a hálózatodnak, lásd a cryptoware-ek amiből volt ami kihasználta, akkor mekkora lesz a vezetőség feje, és mennyi érdemi melóból fogsz kiesni? Erre szervezet szinten szánni kell erőforrást, vagy ha beüt egy probléma, akkor csendben és fa arccal tudomásul venni.

Egyébként a tetszőleges eszközök mindenféle támogatottsága finoman szólva is erős kihívásokkal kűzd. Hiába készülhetne rájuk újabb fw, már nem készül... hátköszi.

Pont ez az: ez érdemi munka neked, nekem. De NEM termel AZONNAL pénzt. A vezetők szerint. Nincs ezzel gond, amíg be nem üt a krach.

A probléma másik fele, hogy a még forgalmazott eszközökhöz sem készül új fw. Kijött egyszer, talán csinálnak hozzá 1-2 új release-t, aztán úgy hagyják. Még adott gyártón belül is sokszor kiszámíthatatlan, hogy meddig adnak ki fw-t hozzá. Nettó gusztustalanság.

A nagyobbaknak azért van nyilvános EOL-policyjuk és ezt tartani is szokták. Az más kérdés, hogy az egyes komponensek vajon milyen idősek. Az egyik vezető tűzfalgyártó pl. a legfrissebb rendszerén is 3.1-es kernelt használ, és még nem jutott el addig, hogy a management felületén viszonylag könnyedén ki lehessen kapcsolni mondjuk a tls1.1-et.

Nem kell ehhez blogokat, statisztikákat, post mortem riportokat olvasni. Vannak technikai eszközökkel kezelhető problémák, vannak, amik csak szervezeti, humán eszközökkel kezelhetőek (ez is lenne a HR egyik feladata például), és a kezelhetetlen tényezők a te szempontodból.
Nyilván ha CEO / CTO vagy tulajdonos vagy a cégnél, akkor bizonyos szempontból egyszerűbb helyzetben vagy. Más helyzetből meg rosszabban, mert a beosztottaid elrejtik / átformálják / hazudnak a lényegi információkról.

Az alábbi lista szigorúan magánvélemény, nagy valószínűséggel több kolléga, szakember is egyetért vele:
1. User error. Ha nincs felhasználó, akkor nincs gond 90%-ban.
2. Vezetői hibák. Mondhat bármit az IT, ha odafönt totál analfabéták ülnek, akkor fölöslegesen tépi a száját az IT. Jobb esetben vagy IT security team, de ez nem segít, ha odafönt süketek. Ezért kell alkalmazni a VSP elvet (=védd a segged papírral) és az MVP protokollt (=más valaki problémája).
3. Technikailag frissítetlen, magukra hagyott rendszerek. Ha egy nagy cégnél van 200 rendszer, kijön 2-3 naponta egy CVE (nem 0-day), mindenben kell követni az ITIL elveket, van havi 1-2 órád patchelni és van 4-5 ember erre (persze az application support team NEM partner), akkor kiszámolhatod, hogy átlagosan hány napig patcheletlen egy rendszer. Továbbá a patchelés nem termel pénzt közvetlenül az üzlet szerint, ergo felesleges.
4. Fluktuáció. Egyszerűen elvész az információ a fluktuáció miatt. És amiről mindenki azt hiszi, hogy már megoldódott, az nem oldódott meg, mert XY már nem oldotta meg a hibát, elment már a cégtől.
5. Általános leszarom mentalitás: Jól van az úgy, működik, nem? Akkor minek nyúljunk hozzá?
6. Nincs a rendszernek gazdája klasszikus értelemben. Nincs olyan ember, aki teljesen átlátná a rendszert, lenne hozzá jogosultsága és hatásköre, hogy rábólinthasson a frissítésre, változtatásra. Elveszik az információ.

Ez a lista gyakorlatilag cégmérettől független. Vannak minimális különbségek nációtól, szektortól függetlenül. Amíg az IT security, a kockázatok nem árazhatóak be, nincs rájuk KPI, addig nem veszik komolyan. A kör bezárult.

egyetertek. de kiegeszitenem annyival a frissitesek temat, hogy:

- soha nincs megfelelo teszt kornyezet, mert miert vegyen a ceg minden hardverbol/szoftverbol 2-t ha csak 1-et hasznalnak

- ha teszteles nelkul patcheled az eleset, es emiatt elromlik valami (es gyakran el szokott), akkor te vagy az oka.

inkabb nem patchelsz, nem faj fejed...