Projekt

Általános

Profil

Hírek

Person3 KÖZINFORMATIKA Támogatás: Új adathalászati módszer jelent meg az interneten

KI Gerencsér Lajos adta hozzá több, mint 2 éve

(Forrás - Nemzeti Kibervédelmi Intézet)

A Wordfence figyelmeztetést adott ki egy, a Gmail és más népszerű webes alkalmazások elleni elterjedt és hatékony adathalászati technikáról. A figyelmeztetés legfőbb célja a biztonságtudatos viselkedés fokozása, további cél a segítségnyújtás informatikával csak felhasználói szinten foglalkozók számára az adathalász támadások, hitelesítő adatok eltulajdonításának hatékony megelőzése érdekében.

Az új és hatékony adathalászati módszer az elmúlt időszakban főként a Google levelező szolgáltatását, a Gmail-t célozta meg, de más elterjedt szolgáltatások is célpontokká válhatnak. A módszer működése rendkívül egyszerű és nagyon megtévesztő. A támadó egy e-mailt küld az áldozata Gmail-címére annak egy ismerősétől, akinek már hasonló módon feltörték a postafiókját.

Az e-mail tartalmaz például egy képet egy csatolmányról és mivel a feladó ismert, ezért ez nem ad okot a gyanakvásra. A mellékelt képre kattintva előnézet helyett azonban egy újabb ablak ugrik fel, amely ismét a Gmail-be való belépéshez szükséges adatokat kéri be. A böngésző címsorában „accounts.google.com” felirat megjelenése megnyugtatja a felhasználót, és begépeli jelszavát. Ekkor már meg is valósul az adathalászat, a felhasználói adat kompromittálódása megtörtént.

A támadók röviddel azután, hogy megszerezték a felhasználó jelszavát, be is lépnek a postafiókba. Ott felhasználják valamelyik, épp aktuális tárgykörhöz tartozó meglévő levelezés csatolmányát és a címzetti listán szereplőknek levelet küldenek a felhasználó nevében, hogy az ő adataikat is megszerezzék az áldozatéhoz hasonló módon. Ha a támadó már hozzáfér a felhasználó postafiókjához, akkor ezen felül további károkat is okozhat, hiszen számos egyéb személyes adathoz is hozzájuthat, akár jelszó visszaállítást is kezdeményezhet más szolgáltatásokhoz.

Az ilyen és ehhez hasonló támadásokkal szembeni védekezés legfontosabb része, hogy mindig figyelmesen ellenőrizzük a böngésző címsorát, azaz, hogy a megfelelő, általunk kért weboldalon történik-e a bejelentkezés.

Egy ismert támadási módszer esetén az alábbi szöveg jelenik meg a címsorban:
data:text/html,https://accounts.google.com/ServiceLogin?service=mail

A címsor bal szélén lévő „data:text/html” rész egy adat URL, amely okán egy egész file-t tartalmaz a böngészőnk címsora. Ezt használja ki az adathalász módszer, ugyanis ez a fájl fog megnyílni egy új ablakban, ezáltal létrehozva a hamisított Gmail-es belépési oldalt, ami a támadónak továbbítja felhasználó nevünket és jelszavunkat.

Tehát mindig szükséges ellenőrizni, hogy a „https” protokollt jelző rész előtt ne szerepeljen semmilyen előtag. Az eredeti Gmail belépés esetében például így kell kinézni a címsornak:
https://accounts.google.com/ServiceLogin?service =mail…

További fontos árulkodó jel lehet még, hogy a Gmail által is használt „https” protokoll esetén a címsor bal szélén (böngészőnként eltérő módon) egy lezárt zöld lakatnak kell megjelennie és a https feliratnak is zöld színűnek kell lennie. Ezek hiánya esetén a bejelentkezést célszerű megszakítani.

Az adathalászat megnehezítésére érdemes a két lépcsős azonosítást is engedélyezni.
Erről bővebben az alábbi linken olvashat: https://www.google.com/landing/2step/

Szintén hasznos a „Legutóbbi fióktevékenység” funkció, ahol az ellenőrizhető, hogy hol és mikor léptünk be postafiókunkba és hol vagyunk jelenleg is belépve. A gyanús bejelentkezéseket természetesen meg is szakíthatjuk!
Erről bővebben az alábbi linken olvashat: https://support.google.com/mail/answer/45938?hl=hu

Forrás:

https://www.wordfence.com/blog/2017/01/gmail-phishing-data-uri/

Person3 KÖZINFORMATIKA Támogatás: A Közinformatika Támogatási Oldal Dokumentum tárának leírása

KI Gerencsér Lajos adta hozzá több, mint 2 éve

A Projektek/42 Településnév Dokumentumtár -ba kerülnek az IBR anyagok végleges változatai. A tár kezeléséhez a Település jegyzője, rendszergazdája valamint A Közinformatika részéről a fejlesztők illetve a vezetők férnek hozzá.
A felvitel menete a következő: a fenti képen látható Dokumentumok menüpontot kiválasztjuk,

Majd az "Új dokumentum"-ra kattintva

a fájltól független címet adhatunk, és a leírásban jellemezhetjük a dokumentumot.

a feltöltést a "Choose file" gombbal kezdeményezhetjük,
a fájl névre vonatkozó szabályozás:
mindig a pontos fájl nevet adjuk meg a verzió számmal együtt, ha ezt nem tudjuk a B00IT Biztonsági dokumentumok listája K1 v1.0
tartalmazza a pontos elnevezést, ha még verziózás előtti a dokumentum a név után a Régi felirattal lássuk el a megjegyzés mezőben, itt írhatunk a fájlról információkat illetve jelölőket tehetünk.
A Dokumentumtárba csak olyan fájl tehető ami végleges! Ellenőrzötten helyes adatot, adatokat tartalmaz!

Person3 KÖZINFORMATIKA Támogatás: OVI űrlap 4.51 (hibajavítás)

KI Gerencsér Lajos adta hozzá több, mint 2 éve

(Forrás NEIH)
Az Osztályba sorolás és védelmi intézkedés űrlap 4.50 verzióján bejelentés alapján hibát azonosítottunk: a biztonsági osztály kiszámítása a bizalmasság, sértetlenség és rendelkezésre állás értékéből – ebben az egy verzióban – sérült.

Hatóságunk honlapján, az Űrlapok menüpontból 2017. március 6-ától letölthető a 4.51 verzió, melyben az említett hibát javítottuk – ezzel egyidejűleg a 4.50 verziót eltávolítottuk.

Ha az Ön szervezete a 4.50 verzióval adatszolgáltatást tett, azt nem szükséges megismételni, mivel az XML-be exportálható adattartalmat a hiba nem érinti.

Person3 KÖZINFORMATIKA Támogatás: GYIK (forrás NEIH)

KI Gerencsér Lajos adta hozzá több, mint 2 éve

Mi a feladata az elektronikus információs rendszerek biztonságáért felelős személynek?

  1. Elkészíti és naprakészen tartja a szervezet informatikai biztonsági szabályzatát.
  2. A szervezet elektronikus információs rendszereit - adatszintű megközelítéssel - a bizalmasság, sértetlenség és rendelkezésre állás elve szerint 1-től 5-ig terjedő skálán biztonsági osztályba sorolja.
  3. A fejlesztést végző, üzemeltetést végző, üzemeltetésért felelős és információbiztonságért felelős szervezeti egységeket - ha ezek az érintett szervezetnél léteznek - 1-től 5-ig terjedő skálán külön biztonsági szintbe sorolja.
  4. Feltárja az azonosított elektronikus információs rendszerek adminisztratív, fizikai és logikai védelmi helyzetét, illetve az önálló biztonsági szintbe sorolt szervezeti egységek védelmi helyzetét.
  5. Ha az aktuális védelmi helyzet a biztonsági osztályokhoz vagy szintekhez jogszabályban megkövetelt védelmi helyzetnek pillanatnyilag nem felel meg, cselekvési tervet készít a hiányosságok megszüntetése.
  6. Gondoskodik az informatikai biztonsági szabályzat folyamatos betartásáról és a cselekvési terv végrehajtásáról.

Kit lehet kijelölni elektronikus információs rendszer biztonságáért felelős személynek?

Elektronikus információs rendszer biztonságáért felelős személy az lehet, aki felsőfokú végzettséggel, és az alábbi 5 képzettség közül legalább 1-gyel vagy a lejjebb felsorolt 5 releváns szakterület közül legalább 5 év tapasztalattal rendelkezik:

Nemzeti Közszolgálati Egyetem elfogadható képesítése:
elektronikus információbiztonsági vezető

ISACA elfogadható képesítései:
Certified Information Systems Auditor (CISA)
Certified Information Security Manager (CISM)
Certified in RIsk and Information Systems Control (CRISC)

(ISC)2 elfogadható képesítése:
Certified Information Systems Security Professional (CISSP)

Releváns szakterületnek minősül:

információbiztonsági irányítási rendszer tervezése, kialakítása, működtetése
információbiztonsági ellenőrzés vagy felügyelet
információbiztonsági kockázatelemzés
információbiztonsági tanúsítás
információbiztonsági tesztelés (etikus hacker tevékenység)

Hogyan kell regisztrálni az elektronikus információs rendszer biztonságáért felelős személyt?

A NEIH-REG űrlap első oldalán a bejelentő szervezet adatait, második oldalán a kijelölt elektronikus információs rendszer biztonságáért felelős személy adatait kell megadni. Amennyiben a felelős más szervezet munkavállalója, úgy a harmadik oldalon a munkáltató adatait is meg kell adni.

Az űrlaphoz csatolni kell:

a felelős személy feladatához szükséges végzettséget, szakképzettséget és büntetlen előéletet igazoló okiratok másolatát
a felelős személyt kijelölő dokumentum (kinevezési okirat, munkaköri leírás, megbízólevél vagy szerződés) kivonatát
A NEIH-REG űrlapot az ÁNYK alkalmazáshoz való telepítés után lehet megnyitni és kitölteni.

A NEIH-REG űrlap beküldésének módját a Regisztráció menüpont részletezi.

Hogyan kell beküldeni az informatikai biztonsági szabályzatot?

A NEIH-DOK űrlapon meg kell adni a bejelentő szervezet adatait, illetve a csatolt szabályzat metaadatait.

A NEIH-DOK űrlapot az ÁNYK alkalmazáshoz való telepítés után lehet megnyitni és kitölteni.

A NEIH-DOK űrlap beküldésének módját az Adatbejelentés menüpont részletezi.

Hogyan kérhetek engedélyt elektronikus információs rendszer külföldön történő üzemeltetéséhez?

A NEIH-002 űrlapot az ÁNYK alkalmazáshoz való telepítés után lehet megnyitni és kitölteni.

A NEIH-002 űrlap belüldésének módját a Külföldi adatkezelés engedélyezése menüpont részletezi.

Mi számít egy elektronikus információs rendszernek?

Egy elektronikus információs rendszernek kell tekinteni az azonos célból kezelt adatok kezelésében, feldolgozásában résztvevő erőforrások (technikai eszközök, személyek, eljárási szabályok) együttesét.

Ennek alapján:

Több elektronikus információs rendszernek lehetnek közös rendszerelemei.
Egy elektronikus információs rendszernek lehetnek külső közreműködő tulajdonában álló rendszerelemei.
Mi alapján kell megállapítani egy elektronikus információs rendszer biztonsági osztályát?

Kockázatelemzést kell végezni annak a meghatározott adatkörnek a bizalmasságát, sértetlenségét, rendelkezésre állását befolyásoló tényezőkre, amely adatkör alapján az adott rendszer lehatárolásra került.

Ha az elektronikus információs rendszer külső közreműködőt is érint, akkor ki felel a biztonsági osztályba sorolásért?

A biztonsági osztályba sorolás minden esetben az adatgazda feladata.

A biztonsági osztályhoz kapcsolódó védelmi intézkedések megvalósításával kapcsolatos felelősségi köröket - ha azokat jogszabály nem állapítja meg - szerződésben kell rögzíteni a közreműködő felek számára.

Mikor kell felülvizsgálni a biztonsági osztályba, illetve szintbe sorolás eredményét?

A biztonsági osztályba sorolás eredményét új elektronikus információs rendszer be- és kivezetésekor vagy az azzal összefüggő adatkezelési célok jelentős változása esetén, de legalább 3 évente mindenképpen felül kell vizsgálni.

A biztonsági szintbe sorolás eredményét minden alkalommal, amikor új információbiztonságért felelős, üzemeltetésért felelős, üzemeltetést végző vagy fejlesztésért felelős szervezeti egység alakul, illetve megszűnik, felül kell vizsgálni.

Hogyan kell dokumentálni a biztonsági osztályba, illetve szintbe soroláshoz tartozó védelmi intézkedéseket?

A biztonsági osztályba sorolást és a hozzá kapcsolódó védelmi intézkedéseket a NEIH-OVI űrlapon kell rögzíteni: minden azonosított elektronikus információs rendszerhez külön űrlapot kell kitölteni. Kitöltés után egy-egy XML fájl előállítható mindegyikből, melyeket az Adatbejelentés menüpont szerint kell a hatósághoz eljuttatni.

Az XML fájlokat egy közös tömörített archívumban, a NEIH nyilvános PGP kulcsával kell titkosítani. Ha a bejelentő szervezetnél az ehhez szükséges alkalmazás nem áll rendelkezésre, akkor az archívumot jelszóval kell védeni, és a jelszót az adatbejelentéshez használt csatornától eltérő csatornán kell eljuttatni a hatósághoz. Ezzel kapcsolatos részletekről telefonon adunk tájékoztatást, lásd: Kapcsolat.

Mi a különbség a NEIH-OVI űrlap 3. és 4. nagyverziója között?

A 3.xx verzió csak a biztonsági osztályba sorolás eredményének és az ahhoz kapcsolódó védelmi intézkedések dokumentálására szolgál. A 4.xx verzió lehetőséget ad a cselekvési terv kivonatolt rögzítésére is.

Részletes leírás a NEIH-OVI űrlap mindkét verziójához megtalálható az Űrlapok menüpontban.

Mit kell tartalmaznia egy cselekvési tervnek?

A cselekvési terv a megállapított biztonsági osztályokhoz illetve szintekhez kötelezően tartozó védelmi intézkedések megvalósításának nyomon-követhetőségét szolgálja.

Tartalmaznia kell legalább az elvárt intézkedések megvalósításának határidejét a jogszabályi határidővel összhangban. Ajánlott, hogy tartalmazza a felelősségi köröket, illetve az olyan külső tényezőket, melyek az időben történő megvalósítást várhatóan befolyásolják.

A cselekvési terv elkészítésére az annak alapjául szolgáló biztonsági osztályba vagy szintbe sorolás vezetői jóváhagyásától számítva 90 nap áll rendelkezésre.

A cselekvési tervet - kivéve, ha azt a hatóság az Ibtv. 16. § (1) bekezdésére hivatkozva kéri - nem kötelező eljuttatni a hatósághoz.

Meddig kell megvalósítani a biztonsági osztályok és szintek által indokolt védelmi intézkedéseket?

A besoroláskor meghatározott biztonsági osztályokhoz és szintekhez tartozó követelményeknek fokozatosan kell eleget tenni: az első besorolástól számítva minden újabb biztonsági osztály vagy szint eléréshez 2-2 év áll rendelkezésre. Működő, már besorolt elektronikus információs rendszerek biztonsági osztályának felülvizsgálata, illetve működő, már besorolt szervezeti egységek biztonsági szintjének felülvizsgálata nincs hatással a megvalósítás jogszabály szerinti határidejére: azt mindig az első besorolástól kell számítani.

Minden egyes elektronikus információs rendszerhez, illetve szervezeti egységhez kapcsolódó határidők önállóan (az életciklus egyenkénti követésével), az adott rendszer vagy szervezeti egység első besorolásától számítandók.

Person3 KÖZINFORMATIKA Támogatás: A zsarolóvírus (ransomware)

KI Gerencsér Lajos adta hozzá több, mint 2 éve


A zsarolóvírus (ransomware) olyan kártékony szoftver, amely titkosítja a számítógépen és a mobil eszközökön található fájlokat, majd váltságdíjat követel azok feloldásáért. A szoftver fizetési határidőt is szabhat, melynek lejárta után akár végérvényesen elérhetetlenné teszik az adatokat.

Jellemzően fertőzött e-mailekkel terjed, csatolt tömörített állományokban található. A levelekben a támadók számlákra, hivatalos dokumentumokra hivatkozva próbálják rávenni az áldozatot, hogy nyissa meg a mellékletet. Amennyiben ez megtörténik, a program telepíti magát és további kártékony kódokat igyekszik letölteni a megfertőzött eszközökre. Az esetleges váltságdíj kifizetése nem javasolt, mivel semmilyen garancia sincs arra, hogy kapunk kódot a visszaállításra, és hogy az működőképes is lesz.

Az operációs rendszer, illetve az alkalmazások (Adobe Flash, Java) hibajavításainak rendszeres telepítésén túl mindenképp javasolt valamilyen vírusvédelmi megoldás használata, illetve naprakészen tartása (termékverzió, felismerési adatállományok). Adatainkról egy elkülönített, és fizikailag is leválasztható meghajtóra rendszeresen mentéseket kell készíteni. Fontos a biztonságtudatos internet használat: ismeretlen feladótól érkezett e-mailekben ne nyissuk meg a mellékletet, főleg ha ez egy tömörített állomány! A zsarolóvírusok gyakran .exe, vagy .pdf kiterjesztésű mellékletben érkeznek. Egy esetleges fertőződés esetén a fertőzött gépet azonnal le kell választani a hálózatról.

Hordozható adattárolót (pendrive, külső merevlemez) sem szabad csatlakoztatni, hiszen ezzel a fertőzést tovább lehet vinni egy másik számítógépre. A meghajtó teljes formázása javasolt, ezzel biztosan eltűnik a vírus minden nyoma. Csak a teljes operációs rendszer újratelepítése, valamint az aktív vírusvédelem bekapcsolása után lehet az adatokat az archív mentésekből helyreállítani.

A ransomware-ek számos variánsát sikerült már feltörni (vagy a szoftver készítői maguk publikálták a visszafejtéshez szükséges mester kulcsot, pl. a TeslaCrypt esetében), így célszerű lehet a titkosított állományok megőrzése.

Ebben nyújthat hatékony segítséget a CryptoSearch nevű, Michael Gillespie biztonsági kutató által a Windows platformra készített ingyenes program, amely egy folyamatosan frissülő online adatbázist használva (ID Ransomware) jelenleg kb. 240 variáns felismerésével képes automatikusan detektálni a titkosított fájlokat és róluk egy, a felhasználó által választott meghajtóra - az eredeti könyvtárszerkezet megtartásával - mentést készíteni.

A zsarolóvírusokról az alábbi hivatkozásokon további információt találhat:

http://www.eset.hu/zsarolovirusok
https://support.symantec.com/en_US/article.HOWTO124710.html
http://www.pandasecurity.com/mediacenter/malware/what-is-ransomware
http://www.mcafee.com/us/security-awareness/articles/ransomware.aspx
https://biztonsagportal.hu/a-linux-sem-jelent-akadalyt-a-brutalis-killdisk-virusnak.html
http://www.welivesecurity.com/2017/01/05/killdisk-now-targeting-linux-demands-250k-ransom-cant-decrypt/

Person3 KÖZINFORMATIKA Támogatás: ASP rendszer bevezetése

KI Gerencsér Lajos adta hozzá több, mint 2 éve

Tisztelt Ügyfelünk!


Ahogyan a Magyar Államkincstár napokban küldött levele is jelzi, „az ASP rendszer bevezetéséhez kapcsolódó pályázati kiírás alapján minden pályázónak szükséges a szabályait módosítania.”
Ezek egyike az Informatikai Biztonsági Szabályzat (IBSZ). Az IBSZ, amely a 2013. évi L. törvény szerint kiépített és működtetett Infomációbiztonsági rendszer központi szabályozó dokumentuma, módosítása alapvető, hiszen új rendszerek kerülnek bevezetésre, amelyekkel összefüggésben új biztonsági megoldások is használatba kerülnek (pl. azonosító kártya). Az IBSZ mellett természetesen számos fontos dokumentum módosítása szükséges (Iratkezelési szabályzat, Ügymenetfolytonossági terv, Katasztrófaelhárítási terv, Karbantartási terv, Mentési rend, Informatikai eszközök leltára, Licenszleltár, Szakrendszerek leltára és biztonsági osztályba sorolása, Kockázatelemzés és kockázatkezelés, Intézkedési tervek, Információbiztonsági stratégia, stb.) Az aktualizált dokumentumok közül az IBSZ-t kötelező a Nemzeti Elektronikus Információbiztonsági Hatóság (NEIH) részére megküldeni, továbbá szükséges egyéb adatszolgáltatási kötelezettségünk felülvizsgálata és aktualizálása (NEIH REG, NEIH DOC, NEIH SZVI, NEIH OVI űrlapok, amelyek itt elérhetőek: http://www.neih.gov.hu/node/88?q=node/31). Az adminisztratív változások mellett fontos a logikai és a fizikai biztonsági intézkedések körének revíziója és frissítése, a megváltozott körülményeknek megfelelő oktatások (rendszergazdai és felhasználói) megtartása és az azt követő üzemeltetési időszakba elengedhetetlen a megújított rendszer belső auditja is.

A KÖZINFORMATIKA Közigazgatási Informatikai Szolgáltató Központ Nonprofit Kft. által az ASP program keretében vállalt szolgáltatásoknak a fentiek részét képzik.

Üdvözlettel:

VÉKÁS Sándor
ügyvezető

Person3 KÖZINFORMATIKA Támogatás: Mi az az OVI-űrlap?

KI Gerencsér Lajos adta hozzá több, mint 2 éve


Az űrlap egy számolótáblákból álló munkafüzet-sablon, melynek segítségével az érintett könnyebben
sorolhatja biztonsági osztályba elektronikus információs rendszereit bizalmasság, sértetlenség
és rendelkezésre állás szempontjából, valamint egységesen dokumentálhatja a megállapított osztályokhoz
tartozó követelmények teljesülését vagy hiányát, végül meggyőződhet arról, hogy a
rendszer pillanatnyilag mely biztonsági osztály követelményeit teljesíti maradéktalanul.

Person3 KÖZINFORMATIKA Támogatás: OVI űrlap 4.50

KI Gerencsér Lajos adta hozzá több, mint 2 éve

Mától elérhető az Osztályba sorolás és védelmi intézkedés űrlap 4.50 verziója, és a frissített kitöltési útmutatóval együtt letölthető az Űrlapok menüpontból.

Az űrlaphoz rendelt XML-sémaleíró dokumentumban és magában a leképezésben kisebb hibát javítottunk, ezt kihasználva az Összegzés fülre felkerültek az elektronikus információs rendszer működését érintő szervezeti szerepkörök, ezzel segítve a biztonsági osztályba sorolással és védelmi intézkedésekkel kapcsolatos feladatmegosztást, különös tekintettel az önkormányzati ASP keretében azonosított elektronikus információs rendszerekre.

Mostantól az űrlap által használt adatterületen kívüli rész egyik lapon sem védett, így igény szerint könnyen készíthetők saját célú feljegyzések, melyeket azonban a hatóság nem vesz figyelembe, mivel az elvárt adatszolgáltatási forma továbbra is az XML.

A 3.1.3., 3.3.3. és 3.3.11. füleken a sorok mostantól csak akkor lesznek színnel kiemelve, ha amellett, hogy a biztonsági osztály alapján elvárt az intézkedés, az egész lapra vonatkozó kizáró feltétel nem teljesül.

A részösszegző lapok fejléceiről és az összegző lap egészéről eltávolítottuk a feltételes formázást a "Megvalósult-e" oszlopból, mivel félrevezető volt, hogy az egyes intézkedéscsoportok megfelelősége általában nem azonos azzal, hogy egy teljes intézkedéscsoport megvalósul.

A NEIH-OVI űrlap 3.15 verziója mától, a 4.31 verzió pedig április 1-jétől nem elérhető. Ha az ügyfél szervezet egy adott elektronikus információs rendszerre az aktuálisnál korábbi verziójú űrlapot töltött ki, azt a biztonsági osztályba sorolás következő felülvizsgálatáig benyújthatja a védelmi intézkedés katalógusnak való megfelelőség igazolása céljából.

Person3 KÖZINFORMATIKA Támogatás: Cisco Smart Install Protocol sérülékenysége

KI Gerencsér Lajos adta hozzá több, mint 2 éve

A Kormányzati Eseménykezelő Központ tájékoztatást ad ki, hogy a Cisco Smart Install Protocol visszaélésre ad lehetőséget.

Több biztonsági kutató is beszámolt a közelmúltban arról, hogy a Cisco Smart Install (SMI) protocol-t használva, egy nem hitelesített távoli támadó egy új IOS image-t betöltve képes lehet a startup-config beállításokat módosítani és a készüléket újraindítani. Ezen kívül a rosszindulatú felhasználó képes lehet magasabb jogokkal CLI parancsokat futtatni azokon a switch-eken, amin Cisco IOS vagy IOS XE fut.

A SMI Protocol a director (központi switch) üzenetét a client hitelesítés nélkül elfogadja. Ennek következtében a támadó által létrehozott, speciálisan szerkesztett SMI protocol üzenetekkel az alábbiakat lehet elérni:

Megváltoztatható a TFTP szerver elérhetősége a client-nél
Ennek következtében TFTP szerverről harmadik fél által létrehozott IOS image-t töltheti be a client
A támadó által üzemeltetett TFTP szerverre lementhetőek az eredeti startup-config beállítások, majd a támadás végén ezek visszamásolhatóak
Az eredeti startup-config beállításokat rosszindulatú konfigurációra cserélve elérhető, hogy az eszköz bizonyos időintervallumban újrainduljon
A támadó képes lehet magasabb jogokkal CLI parancsokat futtatni, azokon a switch-eken, amin Cisco IOS 15.2(2)E vagy későbbi és IOS XE vagy későbbi verzió fut.
Mivel a protokollt támogató switcheken az SMI gyárilag be van kapcsolva, ezért amennyiben nincs használatban, a fentiekre tekintettel javasolt ezt a beállítást kikapcsolni. Ez két módon tehető meg:

a no vstack paranccsal
azon eszközökön, ahol a no vstack parancs nem érhető el, lehetőség van Interface access control list definiálására (ACL).
A Cisco ezzel párhuzamosan frissítette a kiadott Smart Install Configuration Guide-ját hozzáadva néhány biztonsági tanácsot.

Az esettel kapcsolatban tömeges kihasználásról a Kormányzati Eseménykezelő Központ nem rendelkezik információval, azonban ennek ellenére javasolt a biztonsági intézkedések megtétele.
[[https://tools.cisco.com/security/center/content/CiscoSecurityResponse/cisco-sr-20170214-smi]]

(171-180/185)

Exportálás Atom