A Symantec azt tanácsolja ügyfeleinek, hogy (ideiglenesen) álljanak le a pcAnywhere használatával

Titkosítás, biztonság, privát szféra

Mint az ismert, a Symantec egyes termékeinek forráskódja publikus lett. Na nem azért, mert a cég azt nyílt forrásúvá tette, hanem azért, mert ahhoz illetéktelenek fértek hozzá. Ezt a cég a Facebookon elismerte. De nem csak hozzáfértek a kódokhoz, hanem azok egy részét publikálták is az interneten. A vállalat szerint nem a saját hálózatára törtek be, hanem egy 3rd party-tól szerezték meg illetéktelenek a forráskódokat. Eleinte a Symantec igyekezett nyugtatni az ügyfeleit, állítva, hogy régi - több éves - kódokról van szó és ráadásul az egyik érintett termék már nyugdíjazásra került. Viszont most arról ír a ComputerWorld, hogy a cég azt javasolja ügyfeleinek, hogy a álljanak le a pcAnywhere szoftver használatával addig, amíg ahhoz frissítés nem érkezik. A Metasploit mögött álló H.D. Moore, meglepődött azon, hogy egy Symantec kaliberű cég ilyesmire kéri ügyfeleit.

A részletek itt olvashatók.

( Chronos | 2012. 01. 27., p – 11:30 )

"A vállalat szerint nem a saját hálózatára törtek be, hanem egy 3rd party-tól szerezték meg illetéktelenek a forráskódokat."

Ki az a barom aki kiadja egy ilyen szoftnak a kódját 3rd party-nak?

( sh4d0w808 | 2012. 01. 27., p – 11:36 )

Korábban a Symantec hazudott, amikor azt állította, hogy 3rd party-tól szerezték meg a forráskódokat.

Íme.

-------------------------
Trust is a weakness...

( wladek1 | 2012. 01. 27., p – 12:00 )

Ezzel el is astak magukat; vegervenyesen...

( hokuszpk | 2012. 01. 27., p – 12:10 )

nocsak. a legujabb security auditjuk hibat talalt az eddig tokeletesnek eladott termekben ? :D)

( Replaced | 2012. 01. 27., p – 12:34 )

openssh forrasa is elerheto, megis sokan hasznaljak. nem ertem en ezt :-)

--
NetBSD - Simplicity is prerequisite for reliability

( bounty v | 2012. 01. 27., p – 13:20 )

Nem is értem, miért probléma ez? Rengeteg ismert forráskódú szoftvert használnak, magas biztonságot igénylő célokra is. Vagy netán a zárt kódú program lehet slendrián forráskódú, úgyis megfizetik a birkák?

( pioo | 2012. 01. 27., p – 17:47 )

Én szeretem a pcAnywhere terméket. Szerintem nagyon jó és üdvözlöm azt a lépést, hogy nyílt forrásúvá tették. Jó érzés, hogy meghallgatják a vevőik kívánságát. Szeretem a nyílt forrású alkalmazásokat, mert általában sokkal gyorsabban fejlesztik őket, mint a zártakat.

--
Aki falra szerelt tehennel vitatkozik, olyan mint vonat kerek nelkul, nem jut sehova.

( Csab | 2012. 01. 27., p – 22:56 )

Mi a baj a nyílt forrással?

if( !"fd!Pk".equals(passwd) ) throw new Exception();

A zárt forráskód önmagában semmilyen biztonsági védelmet nem jelent. Ha erre építette a vállalat a biztonságot, akkor cseszhetik a júzerek.

Gondolom viccnek szántad, de már találkoztam ilyen sorral kereskedelmi, zárt termékben.
Valahogy így nézett ki:

if(md5.ComputeHash(GetBytes("p*ssword")).Equals(md5.ComputeHash(GetBytes(input))))

Szóval a srácok már hallottak valamit a biztonságról :)

Mentségére legyen mondva, minimális felelősségű software volt.

Meglehetősen sok cuccban van ilyen. Viszonylag legitim módon lehet teszt kódban (pl unit teszt futás közben nincs LDAP, de mégis kell valami dummy authenticator). Normális körülmények között a teszt kód nem fordul bele a végleges binárisba. Ha valamiért mégis belekerül, akkor ott egyéb komoly bajok is lehetnek.

Aztán előfordul, hogy a telepítés utáni, még az elés jelszó beállítása előtti bootstap folyamat részeként szerepel ilyen kód. Ez már nagyobb antipattern, mert nehéz ellenőrizni, hogy nincs-e olyan támadási vektor, hogy valahogy utólag be lehessen kapcsolni ezt a bootstrap üzemmódot, vagy esetleg valami return to libc-szerű stack manipulációval ráfuttatni a végrehajtást.

Ha meg az éles autentikátor kódban van ilyen, arra nincs mentség.
---
Internet Memetikai Tanszék

Egyrészt nem feltétlenül látszik, mert kereskedelmi termékeknél ma már eléggé jellemző, hogy valami obfuscatort rázavarnak. Más kérdés, hogy ez csak arra jó, hogy "megszűrje" a próbálkozókat, így csak azok fogják tudni visszafejteni, akik eléggé értenek a témához. Az ilyenek pedig már tudnak exploitot is írni.

Egyébként pedig ha nem csak ilyen remote desktopban gondlkodsz, akkor elég sok olyan szerver-oldali alkalmazás juthat eszedbe, aminél az első használatkor tipikusan "admin/admin"-nal kell belépni (utána persze rögtön meg kell változtatni). Na szerinted ezt hogy szokták implementálni?!
---
Internet Memetikai Tanszék

A jelszó hashben "illik" tárolni, mert abból a jelszó nem állítható vissza.

Az "illik" azért van zárójelben, mert ritka kretén az, aki a kódba beleégeti a jelszót.

A probléma ezzel sem oldódik meg, mert ha mindenki látja a letárolt jelszó hasht, ahhoz rohadt erős jelszavak kellenek, nem 8 betűsök.

Az a baj, hogy gyorsulnak a gépek, de 25-50 karakteres jelszavakat az emberi agy már nem képes rendesen kezelni. Szóval a probléma nem egyszerű.

Remélem tiszta, hogy mi az a hash.
- fogod a jelszót
- előállítasz belőle egy bájtsort valamilyen kódolással, ezt letárolod
- a felhasználó beírja a jelszót
- előállítod ugyanazzal a kódolással belőle a bájtsort
- összehasonlítod a bájtsorokat

A bájtsorból a jelszót bizonyos kódoló algoritmusoknál csak brute force kereséssel lehet visszaállítani. Magyarul egyesével mindent végigpróbálni.

Azért írtam 25-50 karakteres jelszavakat. Az lenne biztonságos, mert nem tudsz akkora táblát már eltárolni, csak ahogy kifejtettem, az emberi agy limitál.

Elvekről beszéltem, az MD5-öt szóba sem hoztam.

Egy 50 karakteres táblához 1e+99 jelszót kell tárolni. Nem hiszem, hogy van ekkora kapacitás jelenleg a földön.

Abban igazad van, hogy a szivárványtáblának nem olvastam utána, bocs. Igazából azért mellőztem az utánaolvasást, mert 25-50 karakteres jelszónál már minden trükközés felesleges. Ha egy jelszó feltörése 3-5000 év, akkor szivárvány tábla ide, vagy oda cseszheted az egészet. Elvi síkon közelítettem meg a problémát, nem a gyakorlati ma létező oldalról.

A 8-10 karakteres jelszavak semmi védelmet nem jelentenek.

Tudom, de felesleges a securitybe belebonyolódni.

Készítek egy 10000 karakteres jelszót, amit 10k-s hash-ben tárolok el (matematikailag bizonyítottan jó algoritmussal). Ugorj neki, azt törd fel.
Ha minden századik ütközik egy másikkal, az sem segít rajtad sokat.

A hash önmagában alkalmas a jelszavak tárolására, csak a jelszó hosszával van a gond.

"A hash önmagában alkalmas a jelszavak tárolására, csak a jelszó hosszával van a gond."
Te nem tudod, mi az a hash es mire jo. Osszekevered a csapoajtofuggvenyekkel. A hasheknek soha nem celja bijektivnek lennie, ezt nem vetted figyelembe eddig. Amit te szeretnel, az egy bijektiv csapoajtofuggveny, ilyen is letezik, lasd RSA, illetve Diffie-Hellman . Amirol viszont tudni lehet, hogy rendkivul koltseges kiszamitani egy hashhez kepest.

Nem írtam, hogy kölcsönösen egyértelműnek kell lenni a jelszó hashnek sehol. Vagy ha igen, kérlek mutasd meg.

Akkor miért növeltem meg a hash méretét 10k-ra?

Valószínűleg azért, mert ha 32 bites hash-t választok, akkor az 10000 hosszú jelszó teljességgel felesleges, mert az első 32 karakteren nagy valószínűséggel lesz ütközés egy ennél rövidebb jelszóval.

Magyarul: ha 10000 hosszú jelszót akarsz biztonságosan hash-elni, minimalizálva az ütközést, ahhoz legalább 10000 hosszú hash kell, ha nem több.

Hiába használsz 10000-es jelszót, ha 256 bájtos a hashed. Mert akkor az első 256 jelszónál nagy valószínűséggel lesz ütközés és az idő tört része alatt bejutnak.

Miért ennyire nehéz ezt megérteni??? Őrülten fárasztó.

Ha 10k hosszu a hash egy 10k-s jelszonal, es van kulcsutkozes, akkor sokat nem nyertel vele. Ha meg nincs kulcsutkozes, akkor az bijekcio.
"Valószínűleg azért, mert ha 32 bites hash-t választok, akkor az 10000 hosszú jelszó teljességgel felesleges, mert az első 32 karakteren nagy valószínűséggel lesz ütközés egy ennél rövidebb jelszóval."
A jo hashfuggvenyek peldaul ugy vannak megcsinalva, hogy 1 bit valtozas a bemeneten a kimenet bitjeinek legalabb felet megvaltoztatja.
Abban igazad van, hogy 32 karakteres jelszavakkal van kulcsutkozes, de lesz olyan 32 karakteres jelszo, amivel nincs kulcsutkozes (pont az elobbi miatt).

jelszavaknal ez pont nem (olyan nagy) problema, mert a specialis karakterek (jo esetben) ki vannak zarva, igy joval nehezebb utkozest talalni.

Amugy en igy csinaltam egy protokolban:
1. A szerver ismeri az SHA-1 hash-t a jelszorol es general egy random 64 karakteres stringet, amit atkuld a csatlakozni kivano kliensnek.
2. A user beuti a jelszot es a kliens program legeneralja az SHA-1 hash-t.
3. Az elobb generalt hash-hez hozzadobja a random stringet ES az egeszrol keszit egy MD5 hash-t. A szerver is elvegzi ugyanezt.
4. A kliens atkuldi az MD5 hash-t a szervernek.
5. A szerver osszeveti a ket hash-t es ha egyeznek akkor beenged.

Nem tul egyszeru es valoszinuleg nem is tokeletes, viszont a bejelentkezes mehet titkositatlanul, a jelszavak sehol sincsenek letarolva, es a replay tamadasok sem fognak rajta.

Az, hogy a forum kollega (BaT) egy teljesen legitim modszert irt hashelt jelszok megfejtesere, erre arrogans stilusban erkezett a valasz, mikozben fogalma sem volt rola hogy mire valaszol, hogy mi az a szivarvany tabla, milyen fajta relevanciaval bir az adott temahoz es ennek elleneres is a valasz hozzaszolasbol sugarzik a kioktato hangvetel es arrogancia.
---
Review Home

Szerintem ülj be valami biztonságtechnika alapjaival foglalkozó előadásra egy egyetemen. Egyrészt _senki_ nem fog megjegyezni 50 karakteres random krix-krax jelszót. Az nagy valószínűséggel szimpla szavak egymás után esetleg cifrázva a kis/nagybetűt, itt-ott számot + egy kis zavart, és mindjárt máris lecsökken egy egész kezelhető mennyiségre a szivárványtábla, ha szótárral indulsz neki.

Másrészt jellemzően MD5-t használnak, aminek az értékkészlete már kisebb, mint az 50 alfanumerikus karakter önmagában (Csak laza 51 nagyságrenddel ;). Hiszen 32 db és csak 16 féle van belőle (ha hexastringként írjuk ki).

----------------
Lvl86 Troll

Bocs saxus,

a hozzászólásom azzal kezdem, hogy az emberi agy limitálja a jelszavak hosszát. Leírtam idáig kétszer, de most megteszem harmadszor is.

Az MD5-ről véletlenül sem beszéltem, mert ugye a hash != MD5.

Kérlek állj le és ne izélgess azzal, hogy üljek be egy informatika kezdő tanfolyamra, mert azt mondtam, hogy a számítógép pedállal működik.

Nem mondtam, kösz.

Nem mondtam, hogy nem értesz hozzá, max. azt nem érted, amit mondtam.

Az egész sztoriról nekem a Gyaloggalopp jut leginkább az eszembe.

- Minden amit látsz itt, a tiéd fiam!
- Az ablak papa?
- Nem
- Akkor az ablakkeret
- Nem fiam
- Megvan, a függöny papa!

Körülbelül erről szólt az elmúlt 10 hozzászólás.

:)))

Gondolom az egyszer kiszámolt hasheket szigorúan tilos tárolni és egyből az NSA rohamkommandósai fogják rádrúgni az ajtót, ha ezáltal megpróbálod picit meggyorsítani a törést.

De semmi gond, ismerünk még 1-2 olyan titkosító eljárást, ami elvileg törhetetlen, aztán gyakorlatban mégis van rá trükk.

----------------
Lvl86 Troll

Hát, igen.

Sokkal olcsóbb adni egy csokit Mariskának, mint 100.000 géppel brute force nekiesni a kódtörésnek.

:)

Viszont a Certificate Authority-k például megőrzik a privát kulcsukat.
Mondjuk a Verisign cég csődbe is menne azonnal, ha a feltört privát kulcsukkal elkezdenének weblapokat aláírni.

Ha érték számukra a jelszó/privátkulcs, mert a megélhetésük függ tőle, akkor vigyáznak rá.

Attól hogy kereskedelmi és zárt forrású a termék, még bőven van helye a hakkolásnak.

a) kereskedelmi, zárt termék esetén a megrendelő veri az asztalt minimális késésnél is
b) ha a ficsőr megvan, senkit sem érdekel a kód hatékonysága és tisztasága, főleg hogy zárt forrásról beszélünk (maximum a következő szerencsétlent akinek karban kell tartania)

A b) pont miatt szokták emlegetni az opensource cuccokat mint rosszul tervezett, silány minőségű kódot. Naná, hiszen ott van a public repóban, és mindenki láthatja.

--
http://neurogadget.com/

Azért ez nem egészen így van. Én inkább úgy látom, hogy bár alapvetően mind open, mind closed source szoftverek esetén vannak jól, és rosszul megírt szoftverek, más az oka a minőségnek (vagy annak hiányának).

Open source* szoftverek esetén leginkább a fejlesztők igényességén múlik a szoftver minősége. Nincs megrendelő, aki visszautasíthatná a szoftvert, a felhasználóknak pedig hiába rossz a véleménye, bevételkiesés nem fog emiatt történni. Persze ha megfelelő emberek vezetnek egy projectet, ők visszautasíthatnak kódokat az igényesség hiányára hivatkozva, csak ennek a project szenvedheti kárát az érintett fejlesztők elpártolása miatt (lásd ffmpeg). Viszont nincsenek szigorúan vett határidők, ezért van idő jól átgondolt kódot írni.

Closed source esetén a fejlesztők érdeke az igényesség. Ha rossz minőségű szoftvert készítenek, azt visszautasíthatja a megrendelő, vagy nem fogják megvásárolni a felhasználók. Ráadásul ha egy fejlesztő nem képes betartani a minőségi irányelveket, bármikor elbocsátható és pótolható (abba most ne menjünk bele, hogy ez azért ennyire nem egyszerű). A minőség érdekében a fejlesztés során software review-k során ellenőrzik a forráskódot. Viszont vannak határidők, a fejlesztőket a fejlesztés során fizetni kell, ezért a késés nagyobb költséggel járhat, mint egy kevésbé jól megírt szoftver kiadása. Főleg, ha az adott szoftver a maga területén monopolhelyzetben van. (Jó példa erre a xilinx ise, ami (amennyire én tudom) a xilinx fpga-k kizárólagos fejlesztői környezete. Mivel egy fpga kiválasztásában a fejlesztői környezet sokadrangú szempont, ezért elég, ha a szoftver csak azt a szintet üti meg, ami miatt még nem lesznek a cég termékei kerülendőek.)

*: itt elsősorban azon szoftverekre gondolok, amiket közösségi alapon, profitszerzés célja nélkül fejlesztenek

Closed source esetén a fejlesztők érdeke az igényesség.

Ööö... izé... én több helyen is részt vettem kódátvételben - az utóbbi pár évben a megrendelői oldalon, és a zárt forrású cuccok kódminősége mindig messze rosszabb volt, mint az átlagos open source projektek kódminősége. Tapasztalataim szerint a kódminőség az utolsó utáni szempont, közvetlenül a tesztelésre hagyott elegendő idő előtt. A határidő vége felé pedig megjelennek olyan workaroundok, amelyekről az igényesség jut legutoljára az ember eszébe.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

"a zárt forrású cuccok kódminősége mindig messze rosszabb volt, mint az átlagos open source projektek kódminősége"

Elhiszem, hogy a te esetedben ez így volt, de ebből még nem érdemes általánosítani.

"Tapasztalataim szerint a kódminőség az utolsó utáni szempont, közvetlenül a tesztelésre hagyott elegendő idő előtt. A határidő vége felé pedig megjelennek olyan workaroundok, amelyekről az igényesség jut legutoljára az ember eszébe."

Ezt próbáltam leírni ebben a mondatban, igaz kicsit homályosan fogalmaztam: "Viszont vannak határidők, a fejlesztőket a fejlesztés során fizetni kell, ezért a késés nagyobb költséggel járhat, mint egy kevésbé jól megírt szoftver kiadása."

Nyilván nem minden projecttel tegnapra kell végezni, illetve adott esetben a késés miatti többletköltséget kompenzálhatja a magasabb minőségi követelményeknek megfelelő szoftver alacsonyabb üzemeltetési igénye. Tehát itt több, egymásnak ellentmondó szempont van, és sok esetben sajnos bizonyos szempontok csak a kódminőség rovására érvényesülhetnek. De ez még nem zárja ki, hogy sok esetben jobban megéri jobb minőségű kódra, ezáltal jobb minőségű szoftverre törekedni még az emiatt megnövő fejlesztési költségek és időigény miatt sem.

Értem én, de akárhány hasonló munkakörben tevékenykedő emberrel beszéltem, mind erre panaszkodott: a gyenge kódminőségre és a tesztelés hiányára. Megkérdezhetem, hogy hány zárt forráskódú termék átvételénél voltál jelen? :)
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

( carlcolt | 2012. 01. 28., szo – 00:19 )

Mint minden virusirto gyarto, ez is csak szemetet tud gyartani, gondolom ez latszodik most a kod minosegen is.

A biztonsagtechnika ott kezdodik, hogy grsec/PaX, vagy valamelyik BSD kernel, szerintem egy BSD dev beleolvasna akarmelyik virusirto forraskodjaba, hulyere rohogne magat.

Mi köze a BSD _kernel_ -nek a vírusvédelemhez? Szerintem semmi. Linuxra is szokták mondani hogy immunis a vírusokra, a tény viszont az hogy nem szeretnek rá vírust írni, így viszonylag kevés készült rá eddig. A BSD -kre ez valószínűleg fokozottan igaz. De ez könnyen megváltozhat, az elméleten semmit sem ront.

"Mint minden virusirto gyarto, ez is csak szemetet tud gyartani"

Gondolom a világ összes jelentősebb security cégénél dolgoztál, így megalapozott a kijelentésed.

--
http://neurogadget.com/