Mi történt veled Teamviewer?

HUP cikkturkáló

Különböző netes oldalakon elég furcsa információk szivárognak..
pl: http://www.inquisitr.com/3156809/teamviewer-accounts-hacked-thousands-o…

Mindenesetre, aki nem tudná, pár órája nem működik a Teamviewer, a weboldal nem elérhető.

szerk: úgy néz ki,hogy újra megy, hivatalos infó azonban még nincs.

szerk2: itt a hivatalos info: Service outage

  • 6164 megtekintés

( uid_20269 | 2016. 06. 01., sze – 19:17 )

Nem vette meg a Microsoft.?
--
God bless you, Captain Hindsight..

( gemnon v | 2016. 06. 01., sze – 19:18 )

Szerencsére nem érint (nem a pénztárcámhoz szabták :)). De remélem a Google remotinggal nem fog ilyesmi megesni. :D

( elod v | 2016. 06. 01., sze – 19:18 )

Klassz. Tudtam én mikor inkább nem használtam (csak nagyon kevés gépen) unattendedként.

( Xterm v | 2016. 06. 01., sze – 21:22 )

azért nem volt infó (a weboldalon), mert álltak. bezzeg a twitter-en volt. sosem értettem miért van egy ilyen esetben előbb twittelve a hír, mint az el nem érhető tartalom helyett valami akár "plaintext" oldalon kint az infó. vagy szerződésben állnak az ilyen vackok, hogy ha nem megy, akkor nálunk reklámozd, hogy nem megy? :)

--
xterm

Azért nekik nem biztos, hogy erre elegendő egy mv index.php _haceked.index.php && touch index.html && nano index.html ...

Egy ilyen hyper* rendszernél ez másképp működik, plusz a tweeter az értesíti az érintetteket és nem levélben, publikusan, egy az övéktől független rendszerben. Ha nem is tudatos okokkal, de okkal használnják a tweetert ilyen esetekben is.

most abszurd megoldás az általad vélttől eltérően: virtuális gépek között a kifele nem elérhető beszart helyett elindítani egy backup rendszert, ami akár csak ezt közli? ez van olyan bonyolult, mint egy lámpakapcsoló és még akár szépen is meg lehet csinálni. ezt arra mondtam csak, hogy felteszed én az index.php "átnevezése"-re utaltam :) (amúgy nem).

a tweet szarsággal csak az a bajom, hogy a cégenként "ez vajon milyen üzenőfelületet választ, hol keressem a hivatalos írást" megoldás nekem nem kényelmes. van más általam használt rendszer ami a saját oldalán is a tweetjeit használja beépülővel hírfolyamnak. jó lassú is (van, hogy már régen van friss infó, mégsem látszik, stb).

--
xterm

Azt hittem hogy ez a kérdés nem fog eddig eszkalálódni.

Adott egy (nagy) rendszer, ami nem megbízható. Nem egy ember rakta össze, hanem eleve több csoport, több embere, és nem lehet tudni, hogy az adott rendszer milyen mélyen érintett. Ugye ha a DNS van eltérítve, akkor eleve már nem halálbiztos hogy pont az érintett domain(ek) alá kéne bármilyen információt is elhelyezni.

Sejtésem szerint az érintett adatközpontok operátorai csak arra vártak, hogy mikor kapnak utasítást, hogy azonnal tépkedjék ki az uplinkeket, hiszen a fertőzött rendszeren keresztül ellenőrizhetetlen tevékenységet folytattak a rosszindulatú felhasználók. (Talán ennyire nem, de ilyesmire tippelek.)

Ezek után nem biztos hogy pont az lenne a helyes megoldás, hogy egy frissen kitalált(*) domaint regisztrálni, ahhoz tárterületet, alátolni egy notepaddal megírt valamit, és rávenni a világot, hogy mostantól viszont ott keressen minden információt (és reménykedni, hogy a slashdot effekt miatt nem fossa össze magát kb. azonnal), miközben a twitter, mint különálló rendszer, teljesen behangolva, felkészítve a rendelkezésre áll. És különösen, hogy a felhasználók tájékoztatása elég nagy prioritással él.

Legalábbis én így látom.

*) Ha már régóta létező valami (backup rendszer), akkor mi garantálja, hogy az nincs érintve a jelen támadás által?

természetesen ebben is van igazság. viszont miért pont twitter? vagy miért pont akármelyik másik? leginkább erre akartam utalni. van valami, amit el akarsz érni, nem tudsz. guglizol, hogy ők vajon milyen "betonbiztos" (?) felületet használnak a leállásaik küzhírré tételére? (van szolgáltatás, ami facset, van ami twittert, van aki akármit. persze, ha tudod, hogy a tied mit, akkor tudod merre keresd. de mi van, ha nem? értsd megtalálod, hogy x összedőlt és a twitteren ír róla. fogod _tudni_, hogy hiteles az infó ott? nem. nyilván mondhatod, hogy de a saját domain is lehet hiteltelen. de a kettő közűl a saját a hiteleshez közelibb.

amúgy miért erölteted rá, hogy notepadban összegányolt? :) ez valami becsípődés?

totál teoretikusan (létező rendszerre természetesen nem ok nélkül hajaz:), képzeld el az alábbit. x.host összedől, megtörik, kecskepornóval fertőződik. mivel érzékeny adat, leállítják. és a helyére tolnak egy kikapcsolva várakozó tartalmat (azért az érintettlensége csak garantálható egy readonly infonak, nem?).

ennek van egy előnye. amikor felkersed az x.host-ot, akkor pont ott látod, hogy gond van (akár azt is, hogy hol lesz a twitter, ami hiteles, de a lényeg, hogy náluk van az eredeti, hiteles hír arról, hogy összedőlt. ha elég faék oldal (ettől lehet akár szép és modern is, hogy senki szemét ne csípje), akkor slashdotolni is rohadt nehéz, max lassabb lesz. (amúgy nem).

én így gondoltam. de természetesen ettől bármiképp látható, de ha keresgélnem kell a hírt valamiről _más helyen_, akkor eszembe jut mindig az anno kissé vicces "küldjetek egy sms-t, ha újra működtök" c. telkós bukta háttere.

--
xterm

notepad: felőlem nekiállhatnak akár saját CMS-t is fejleszteni ezért, vagy tehetnek fel wordpress-t, vagy egy sharepoint valamit, de amikor időre megy a balhé, akkor nem biztos hogy ez lenne a cél. És ne becsüld le a notepad-et.

x.host: leírtam. Nem lehet tudni hogy az infrastruktúra mennyire érintett, ráadásul rémlik valami hogy mintha a dns-t matatták volna meg. Ilyenkor jobb biztosra menni. Szerintem.

Miért pont a twitter? Többen használják "realtime" státuszjelentésre, egynek jó.

nem becsültem le a notepad-et ,) sőt. csak degradálásnak éreztem a probléma megközelítésére. amúgy szerintem nem ellent mondunk egymásnak. (bár a "kikapcsolt" infrastruktúra érintettségének mélysége azért vitatható. értem mit akarsz mondani, de nem tudom érted-e, hogy miért zavar, hogy "máshol keressem a hírt, mint amiről szól". (a jelenség nem annyira leállásoknál van csak, hanem működési státuszoknál is; kedvenc példám, amikor a login oldalakra kívánkózó infót fúrumban kell keresni az üzemeltetők szerint.)

--
xterm

Azért nekik nem biztos, hogy erre elegendő egy mv index.php _haceked.index.php && touch index.html && nano index.html ...

Egy ilyen hyper* rendszernél ez másképp működik, plusz a tweeter az értesíti az érintetteket és nem levélben, publikusan, egy az övéktől független rendszerben. Ha nem is tudatos okokkal, de okkal használnják a tweetert ilyen esetekben is.

( Imo | 2016. 06. 02., cs – 09:19 )

Mivel DNS hijack biztosan történt ellenük, nem kizárt, hogy a kliensek is veszélybe kerültek. Kérdés milyen védelem van a kliensekben, hogy észrevegyék, ha mondjuk a hackerek a saját szerverükre irányitották a forgalmat a DNS eltéritésével. Azaz el lehet-e hitetni a klienssel, hogy a jogos teamviewer szerverrel állnak kapcsolatban és ha igen, akkor mire lehet rávenni a klienst igy, valószinű bármire. Legalábbis, ha nem kliens oldali jelszó van beállitva a kapcsolódáshoz, hanem pl. teamviewer accounthoz kötötték a kliens elérését.

Én ezért használok 99,999%-ban inkább rdp-t, mint teamviewer-t.

Én is ahol van, amin nincs ott meg Chrome Remote Desktop (persze a RemoteAccessHostFirewallTraversal tilva :)). Az, az egy biztos, hogy nem dől be a DNS támadásnak (nem hajlandó saját xmpp szerverre csatlakozni mert nem tudja igazolni, hogy Google :()
Igazából ez tetszene saját "access" szerverrel.