KRITIKUS / CRITICAL - RackForest ügyfélportál rendszer feltörése

Szerverek

Nem bízom meg bennük ezentúl. Szolgáltatási színvonalban, árban hasonlót tudtok javasolni valamit?

https://pastebin.com/TL74qKkY

  • 6701 megtekintés

( anthony_ v | 2019. 04. 26., p – 21:17 )

Azt hittem csak valami átverés de úgy látom sajnos nem!:-(

( b | 2019. 04. 26., p – 21:32 )

minden renccert fel lehet törni. Lépjél be és változtasd meg a jelszavad. Én már megtettem.

--
GPLv3-as hozzászólás.

( mauzi v | 2019. 04. 26., p – 21:35 )

Az vesse rájuk az első követ, aki már megírta a Tökéletes™ szoftvert.

Egyelőre nem tudjuk, hogy történt-e emberi mulasztás. Mielőtt bármit itélkeznénk, várjuk meg a hivatalos kommunikációt.

Ha emberi mulasztás történt - akkor is ott van még az, hogy csak az nem hibázik, aki nem dolgozik. A cégnél pedig többen is dolgoznak...

( Dyl4n | 2019. 04. 26., p – 21:50 )

Vajon milyen portál rendszer fut náluk?
Úgy látom ez nem WHMCS, de funkciókban hajaz rá.

Egyébként a kommunikációt tekintve szerintem korrektek.

+1 Sok ilyet fogunk még látni, mert a cégek inkább ezt lépik meg, mint várják a várható gigabírságot. A GDPR azért hozott pozitív változást az üzemeltetési kultúrába (most már kommunikálniuk kell ha ekkora gebasz történt), de ügyfél oldalon is meg kell tanulni helyén kezelni ezeket a kötelező közleményeket mind negatívumait mind pozitívumait. + https://hup.hu/node/164052#comment-2343756

( suckit | 2019. 04. 26., p – 21:58 )

Drupa 5-öt kellene használni, az itt is bevált. :)

( Fisher v | 2019. 04. 26., p – 22:42 )

Pontosan miért is nem bízol meg bennük?

A szerverek kezdő jelszava (root) elérhető a webes felületen egy egy-kattintásos JS-es védelem után (amely a mögötted álló embertől véd). És ha az egyébként közepesen biztonságos(nak látszó) kezdő jelszót nem változtattad meg, akkor ehhez hozzáférhettek.

Én gyorsan ellenőriztem, hogy honnan volt az utolsó belépés és hála az égnek az irodai IP-ről, mert a tűzfal csak onnan engedi az SSH-t :) De ha 1x kikapcsolom 30-60 percre a tűzfalat (nem szoktam, nem fordult elő, de "gyorsan had lépjek be egy kicsit") 4 év múlva, ne abban az egy órában próbálkozzanak be.

Mondjuk a kezdő jelszó megkapása után mindig cserélni szoktuk, mert a levelezőszerverben furcsán mutat egy törölt levél, benne egy IP cím egy user (root) és egy password: jfkfjfklajfkfjdsf... és amikor a leveleimet viszik el... :) és :(

SUM: RF szolgáltatási szintje nekünk ideális (a jónál jobb), ilyen incident előfordulhat, talulunk belőle, szombati gyorsreagálásra is teszünk így próbát. Még jó hogy nem mi vagyunk az amazon vagy belügyminisztérium...akkor baj lenne a közvetett incidensek kezelésével.

( hzsolt94 v | 2019. 04. 26., p – 23:15 )

Az első gondolatom nekem is ez volt, a második meg hogy inkább megbízom bennük, akik azonnal értesítenek mint valakiben aki elsumákolja.

Ettől függetlenül persze ez most plusz egy pont a saját hardvernek, illetve várom a részletes jelentést.

hogy lehetett volna ezt elsumálkolni? ha nem változtatnak jelszót, akkor is kiderül, mert valaki betud lépni a felhasználókhoz, ha meg változtatnak akkor meg egyértelmű hogy miért.. szóval ezt nem lehetett eltitkolni, nem hozzáállás kérdése, ez kényszerintézkedés..

( Pene | 2019. 04. 27., szo – 01:23 )

Szerintem full korrekt volt tőlük ez a megoldás. Szvsz maradunk is náluk. Mindenki hibázhat, és egyelőre ismert káresemény sem történt.

Törvény szerint:

  • az adatvédelmi incidenst indokolatlan késedelem nélkül, és ha lehetséges, legkésőbb 72 órával a tudomásszerzést követően be kell jelenteni az illetékes felügyeleti hatóságnál;
  • ha az adatvédelmi incidens valószínűsíthetően magas kockázattal jár a természetes személyek jogaira és szabadságaira nézve, az adatkezelő indokolatlan késedelem nélkül tájékoztatja az érintettet az adatvédelmi incidensről;

( nevergone v | 2019. 04. 27., szo – 09:06 )

Szerintem korrekt.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

( opt | 2019. 04. 27., szo – 14:22 )

Vagy pont ezek után lehet megbízni bennük, mert jobban oda fognak figyelni. Azért minden ilyen égés, és őket szakmailag is érdekli, nem T-s vezetőrkől van szó.
Egyébként engem is meglepett, és negatívan érint.
Ár érték arányban szerintem elég jók, nem hinném, hogy egyértelműen lenne jobb ebben a kategóriában.

( zolo | 2019. 04. 27., szo – 18:14 )

Orulj neki,h gyorsan reagaltak es nyiltan, korrekten tajekoztattak, sot meg fejleszteseket is elorevetitettek.
Azert,ha uzemeltettel mar, akkor tudod, hogy sajnos ilyen elofordulhat meg a legnagyobbakkal is.
A kartyaadatok sajnos mar problemasabbak. De ez egy ilyen terulet.

( insomnia v | 2019. 04. 28., v – 15:25 )

Azert mert valamelyik szolgaltatot feltortek, azert jo szolgaltato.
A tobbiek meg biztos nem jelentik be, ezert jobb akit transzparensen feltortek?

Szerintem akik pozitivan alltak hozza a beismert feltoreshez, azok amugy is elegedettek a Rackforest szolgaltatasaval - nem csak technikailag, hanem a kommunikacioval is. Peldaul mi is.
Rendszeresen kapunk korrekt informaciokat karbantartasokkal, fejlesztesekkel kapcsolatban, beleillik ez is a kepbe.

( mgabor v | 2019. 04. 28., v – 20:15 )

Én csak azt nem értem, hogy ez a mondat: "Az okozott kellemetlenségért elnézésüket kérjük!", miért nem így van írva: "Az okozott kellemetlenségért elnézésüket kérjük, szolgáltatása aktuális havi díját természetesen elengedjük!"

Gondolom azért, mert az egy havi díj erősen lyukat ütne a költségvetésükben és elvenné a fejlesztésekre fordítható pénzek egy részét.

Egyébként jó látni, hogy náluk működik a transzparencia.
Én inkább egy ilyen cégben bízom meg, aki mind a jót és rosszat is belemondja az arcomba (értesít róla), nincs sumákolás, uram-bátyám, stb.

Az áraik jók (nekem legalábbis), a support is jó (eddigi közös munkák során mindent meg tudtunk oldani.)
Továbbra is tervezem átmigrálni a VPS-eimet hozzájuk + egy két szolgáltatást.

--------------------------------
...úgyis jönnek...

Akkor azt mondod ilyen és ehhez hasonló esetekben mindig hunyjunk szemet ezek felett, mert elmondták? Nem akarok kötekedni, sajnálom ami történt, de a másik felet is meg kell érteni szerintem, ha már elvárt valami szolgáltatást, vagy nem kellene tenni szerinted semmit? Ha legközelebb az egyik szolgáltatótól kiszivárog az összes személyes adatom, akkor hagyjam, mert amúgy jó arcok? Szerintem az 1 havi kártérítés a minimum ami itt járna. (persze ez csak szerintem)

"Akkor azt mondod ilyen és ehhez hasonló esetekben mindig hunyjunk szemet ezek felett, mert elmondták?"

Azt mondom, hogy jobban megbízom olyan cégben, aki nem kertel, hanem megmondja a jót és a rosszat egyaránt.

"de a másik felet is meg kell érteni szerintem, ha már elvárt valami szolgáltatást"

Maga a szolgáltatás működik (Hosting, DNS, akármi)? Mert ha igen, akkor szolgáltatáskiesés nem volt, amiért járna valami kompenzáció (a szerződésben erre gondolom van kitétel).

"Ha legközelebb az egyik szolgáltatótól kiszivárog az összes személyes adatom, akkor hagyjam, mert amúgy jó arcok?"

Mit tudsz csinálni, ha már kiszivárgott (ha jó arcok, ha nem)?
Visszacsinálni nem lehet, akkor lehet dönteni: szolgáltatóváltás vagy maradás.

Gondolj bele, hogy mi van akkor, ha nem mondják el?
Hamis biztonságban érzi magát az ember ilyenkor, mert ugye arról sem tud, hogy nagyobb veszélynek van kitéve a a netes támadásoknak mint eddig.
Aztán meg ha megtörik a rendszerét, akkor megy a pislogás, hogy ezt hogy.

A kártérítésre ott a szerződés, meg az egyéb jogszabályok, aztán el lehet kezdeni jogászkodni.
Legtöbbször sokáig tart és nem egyértelmű, hogy ki jön ki jól az egészből (kivéve a jogászokat, ők mindkét oldalon keresnek ezzel. :) )

--------------------------------
...úgyis jönnek...

Nem is tudom van-e meg olyan transzparens ceg mint a rackforest. Visszakerni egy havi penzt? Neked oszinten jobb lenne barmi ettol? Visszakapnad az adataidat? Nem hiszem, meg azt sem, hogy a fonokod (persze mar ha van) barmikor visszakert volna egy havi fizut toled, mert elrontottal valami, es odamentel hozza es oszinten bevallotad

____________________
http://szoftvervasarlas.co.hu - szoftverek legjobb áron

Tehát akkor szerinted minden rendben. Rendben van a facebook már lassan heti adatszivárogtatása is. Vagy van kis probléma is meg nagy is? Kérlek rakd ki pastebin-re a személyi igazolvány számod, a lakcímed, a személyi számod, a bakkártya számod, a születési helyed, a családi állapotod, édesanyád nevét. Nekem nem lenne jobb 1 havi pénzvissza lehetőségtől, de akkor ez szerinted rendben van mert transzparens?

( scottscott v | 2019. 04. 28., v – 21:48 )

Edit: duplan ment el az elozo....

( htmm v | 2019. 04. 29., h – 10:55 )

Gondolom mikor mar ok is teljesen biztosak majd kapunk egy reszletesebb leirast, hogy mi tortent, abbol majd kiderul, hogy ok hibaztak-e, vagy csak megszivtak.

Egyik szolgaltatonal sem az a baj, hogy valami tortenik, mert mindig tortenik valami. A jo szolgaltato viszont transzparensen kommunikal es megakadalyozza, hogy ujra ugyan az bekovetkezzen.

--
http://blog.htmm.hu/

Nem hiszem, hogy lesz részletesebb leírás. A blogon sem láttam említést erről. Az ügyfeleket értesítették mert a levelezésben/ticketingben leírt jelszavakat ellophatták, így a jelszavak titkosítás nélkül kerülhettek illetéktelen kézbe. Korrekt tőlük, hogy írtak, de ennyi és nem több. Azt nem fogjuk megtudni, hogy pontosan mi történt, azt meg főleg nem, hogy ki-hol hibázott.

( ne0 | 2019. 04. 29., h – 14:54 )

most jött egyébként részletes infó
félretéve, hogy pozitív vagy negatív a nyílt kommunikáció vs megelőzés, amit nem értek:

1. egy szolgáltató mi a francért nem képes frissíteni az admin rendszerét?
akkor a VPS alatti cuccokat sem frissítik?

2. miért tárol manapság bárki még visszafejthetően jelszavakat??

3. miért kell eltárolni azokat az emaileket, amiben kimegy az ügyfél részére a jelszó, amit ugye elvileg csak az ügyfélnek kellene megismernie?

Én is most kaptam meg a hosszabb levelet:
"egy szolgáltató mi a francért nem képes frissíteni az admin rendszerét?": állandó dilemma, hogy a egy (példaképp írom) wordpress-t azonnal frissítst, amikor megjelenik vagy még lesz benne hiba, ami miatt lesz vX.Y.1-es verzió a vX.Y után.

"miért tárol manapság bárki még visszafejthetően jelszavakat??": talán mert szüksége van rá, hogy felhasználja? Sok 3rd party "dologba" csak jelszóval lehet belépni, amit valahogy el kell tárolnod. Hiába hash-elve rakod el, ha a hash ott van mellette.

"miért kell eltárolni azokat az emaileket, amiben kimegy az ügyfél részére a jelszó, amit ugye elvileg csak az ügyfélnek kellene megismernie?": mert senki nem számít a spanyol inkvizícióra... biztos be lehetne állítani egy SMTP-t vagy mBOX-ot, hogy a "pass"/"jelsz" betűket tartalmazó leveleket ne mentse el, ill. cserélje benne a szöveget. De többen bosszankodnak miatta, mint ahányan szeretik: 1. mysql console előző parancsokban sem látszik az, amelyikbe jelszót írtál. 2. webapp naplózó rendszer nem tárolja a POST-ban kapot jelszót, így nehéz debuggolni. És mindez így van jól, csak nem kényelmes.

persze, csak míg a wordpress ingyenes, ez a hostbill ha jól látom, keményen fizetős, így szerintem jobb telepíteni a frissítést, mint nem
ld. windows update

persze, hogy ott a hash, de van már manapság adaptív verzió, aminél kb. lehetetlen visszafejteni

igen, pont egy pár soros automata php szkriptre gondoltam, ami kitörli ez érzékeny infókat
most kb. ezek jelentették a legnagyobb veszélyt a kiszivárgott adatokban

A kettes ponttal kapcsolatban csak annyit tennék hozzá, hogy ez nem feltétlenül a hoszting szolgáltató hibája. Ha valaki hoszting vállalkozásba kezd, kb. két nagyobb szoftvertermékkel tudja lefedni az ehhez szükséges ügyviteli rendszert: Hostbill vagy WHMCS. Mindkettőnek a gyártója úgy fejleszti a termékeit mind a mai napig, hogy plaintext-ben tárolódnak ezek a kezdeti jelszavak, innentől kezdve hogyan tovább? Persze vissza lehet fejteni az ionCube-olt forráskódokat és átmatatni benne egy str_replace-el a jelszavakat, hogy ne az tárolódjon el a db-ben, de azért aki foglakozott már ilyenekkel, az nem feltétlenül tartja ezt életszerű megoldásnak (pl. széttúrja a hóka-mókát a következő update).
Szóval nem olyan evidens kérdés ez, mégha a felvetéssel - azaz, hogy nem jó ez a plaintext-esdi - 100%-ban egyetértek.

Kevesen ismerik ezeket, na meg sok cég úgy van vele, ha 3 ft-ot tudnak spórolni rajta, akkor az összes többi paraméter a háttérbe szorul.
Kis cégeknek, egyedi megoldásokhoz teljesen jó lesz még egy darabig a shared hosting.
Egyébként rengeteg a VPS/Cloud szolgáltató a megnövekedett igények miatt, és egyre több cég tér át részben/vagy egészben, hogy szolgáltatásként árulja a programját, szóval erőteljesen az az irány, amit írsz, csak még kell pár évtized.
Gondolj bele, ha a sok "profi" PHP bütykölő elkezd pluszba VPS-t is üzemeltetni.